Messages in this thread | | | Date | Fri, 11 Nov 2011 15:29:07 +0400 | From | Konstantin Khlebnikov <> | Subject | Re: [PATCH v2] mm: add free_hot_cold_page_list helper |
| |
Hugh Dickins wrote: > On Tue, 1 Nov 2011, Konstantin Khlebnikov wrote: > >> This patch adds helper free_hot_cold_page_list() to free list of 0-order pages. >> It frees pages directly from the list without temporary page-vector. >> It also calls trace_mm_pagevec_free() to simulate pagevec_free() behaviour. > > Sorry for not speaking up sooner, but I do like this patch very much > (and I'm content with your trace compatibility choice - whatever). > > Not so much in itself, but because it then allows a further patch > (mainly to mm/vmscan.c) to remove two levels of pagevec, reducing > its deepest stack by around 240 bytes.
That's Great. Also I don't like pagevec-based free because we sometimes do extra lru lock-unlock on vector overflow.
> > I have that patch, but keep putting off sending it in, because I want > to show a reclaim stack overflow that it prevents, but the new avoidance > of writeback in direct reclaim makes that harder to demonstrate. Damn! > > One question on your patch: where you have release_pages() doing >> + list_add_tail(&page->lru,&pages_to_free); > > That seems reasonable, but given that __pagevec_free() proceeds by > while (--i>= 0) { > , starting from the far end of the pagevec (the most recently added > struct page, the most likely to be hot), wouldn't you reproduce > existing behaviour more accurately by a simple list_add()? > > Or have I got that back to front? If so, a comment on the > list_add_tail() would help me to remember why - thanks. > > Hugh
Ok, this reasonable. Any way, the second its user: shrink_page_list() puts pages at the front.
| |