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.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>