linux-imx
Public
Source
committed 7a9cdebdcc1x
* Hash based on the pmd of addr if configured with MMU, which provides a good * hit rate for workloads with spatial locality. Otherwise, use pages. */#ifdef CONFIG_MMU#define VMACACHE_SHIFT PMD_SHIFT#else#define VMACACHE_SHIFT PAGE_SHIFT#endif#define VMACACHE_HASH(addr) ((addr >> VMACACHE_SHIFT) & VMACACHE_MASK)/* * Flush vma caches for threads that share a given mm. * * The operation is safe because the caller holds the mmap_sem * exclusively and other threads accessing the vma cache will * have mmap_sem held at least for read, so no extra locking * is required to maintain the vma cache. */void vmacache_flush_all(struct mm_struct *mm){ struct task_struct *g, *p; count_vm_vmacache_event(VMACACHE_FULL_FLUSHES); /* * Single threaded tasks need not iterate the entire * list of process. We can avoid the flushing as well * since the mm's seqnum was increased and don't have * to worry about other threads' seqnum. Current's * flush will occur upon the next lookup. */ if (atomic_read(&mm->mm_users) == 1) return; rcu_read_lock(); for_each_process_thread(g, p) { /* * Only flush the vmacache pointers as the * mm seqnum is already set and curr's will * be set upon invalidation when the next * lookup is done. */ if (mm == p->mm) vmacache_flush(p); } rcu_read_unlock();}/* * This task may be accessing a foreign mm via (for example) * get_user_pages()->find_vma(). The vmacache is task-local and this * task's vmacache pertains to a different mm (ie, its own). There is * nothing we can do here. * * Also handle the case where a kernel thread has adopted this mm via use_mm(). * That kernel thread's vmacache is not applicable to this mm. */static inline bool vmacache_valid_mm(struct mm_struct *mm)