linux-kernel - Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090226171549.GH32756@csn.ul.ie>
Date:	Thu, 26 Feb 2009 17:15:49 +0000
From:	Mel Gorman <mel@....ul.ie>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	penberg@...helsinki.fi, riel@...hat.com,
	kosaki.motohiro@...fujitsu.com, hannes@...xchg.org,
	npiggin@...e.de, linux-kernel@...r.kernel.org,
	ming.m.lin@...el.com, yanmin_zhang@...ux.intel.com
Subject: Re: [PATCH 20/20] Get rid of the concept of hot/cold page freeing

On Thu, Feb 26, 2009 at 12:00:22PM -0500, Christoph Lameter wrote:
> On Thu, 26 Feb 2009, Mel Gorman wrote:
> 
> > The known-to-be-zeroed pages is interesting and something I tried but didn't
> > get far enough with. One patch I did but didn't release would zero pages on
> > the free path if the was process exiting or if it was kswapd.  It tracked if
> > the page was zero using page->index to record the order of the zerod page. On
> > allocation, it would check index and if a matching order, would not zero a
> > second time. I got this working for order-0 pages reliably but it didn't gain
> > anything because we were zeroing even more than we had to in the free path.
> 
> I tried the general use of a pool of zeroed pages back in 2005. Zeroing
> made sense only if the code allocating the page did not immediately touch
> the cachelines of the page.

Any feeling as to how often this was the case?

> The more cachelines were touched the less the
> benefit. If the page is written to immediately afterwards then the zeroing
> simply warms up the caches.
> 
> page table pages are different. We may only write to a few cachelines in
> the page. There it makes sense and that is why we have the special
> quicklists there.
> 
> > If pagetable pages were known to be zero and handed back to the allocator
> > that remember zerod pages, I bet we'd get a win.
> 
> We have quicklists that do this on various platforms.
> 

Indeed, any gain if it existed would be avoiding zeroing the pages used
by userspace. The cleanup would be reducing the amount of
architecture-specific code.

I reckon it's worth an investigate but there is still other lower-lying
fruit.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/