Differential D13485
Improve pmap_free_zero_pages() operations Authored by ota_j.email.ne.jp on Dec 14 2017, 6:26 AM. Tags None Referenced Files
Details
Instead of calling vm_page_free_toq() for each vm_page, create and call a function, vm_page_free_spglist(), that frees a list of vm_pages. I used vm_page_reclaim_run() as a reference when to lock mutex and call vm_page_free_phys(). This reduces the number of locks and also duration of lock. Boot a system and run any commands.
Diff Detail
Event TimelineComment Actions One one of my branches, I have the following static __inline void
pmap_free_zero_pages(struct spglist *free)
{
struct pglist pgl;
vm_page_t m;
int count;
if (SLIST_EMPTY(free))
return;
TAILQ_INIT(&pgl);
for (count = 0; (m = SLIST_FIRST(free)) != NULL; count++) {
SLIST_REMOVE_HEAD(free, plinks.s.ss);
/* Preserve the page's PG_ZERO setting. */
if (vm_page_free_prep(m, false))
TAILQ_INSERT_TAIL(&pgl, m, listq);
}
atomic_subtract_int(&vm_cnt.v_wire_count, count);
vm_page_free_phys_pglist(&pgl);
}Perhaps it makes sense to add a bool argument to vm_page_free_spglist() to instruct it to decrement v_wire_count instead of splitting this into callers.
Comment Actions Replaced pmap_free_zero_pages with vm_page_free_spglist(). Comment Actions I have only style notes about the patch. In my opinion, this is a good change if only due to the reduction of the code duplication. Still. I will wait for one more person agreement with the change, after you fix the style bugs.
Comment Actions I've thought in the past that we should have a subr_pmap.c for sharing code between pmap implementations. Simple routines like this and pmap_resident_count_inc()/dec() could live there initially. Might be that some PV entry management code could be generalized there too. I think the change is fine, modulo style bugs and nits that I pointed out.
Comment Actions Intention of these changes were to improve reuse of code and also reduce number of locks. pmap_free_zero_pages calls vm_page_free_toq() for each page and each vm_page_free_toq() locks vm_page_queue_free_mtx. When I had printed the number of pages being freed in printf while testing, I saw many frees are for many 4 pages and sometimes up to 32. Comment Actions I don't mean to object to the change, but I will note that r330296 subsumes this change since it adds transparent free queue batching to vm_page_free(). That is, most calls to vm_page_free() just add the page to a per-CPU queue, without acquire the free queue lock. One of the motivations for that work was to get rid of some of the ad-hoc batching code we already have and replace it with something more flexible. I'm not sure yet whether that change will eventually land, so I'm ok with the change in this diff. Comment Actions I believe that the good bit of this change is the consolidation of the interface, I mean introduction of the vm_page_free_pages_toq(). Many pmaps use the same code, and x86 pmaps must use delayed free for page table pages. So providing the common interface, which can be adjusted to whatever state the VM evolution suggests, is IMO useful. If you want to trivialize the free of the set of page table pages, it is a single place to do it now. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||