lkml.org 
[lkml]   [2011]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2011-11-11 12:31    [from the cache]
©2003-2011 Jasper Spaans