linux-kernel - Re: [rfc] possible page manipulation simplifications?

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: <20061204145552.GB14383@wotan.suse.de>
Date:	Mon, 4 Dec 2006 15:55:52 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	Mel Gorman <mel@...net.ie>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Memory Management List <linux-mm@...ck.org>
Subject: Re: [rfc] possible page manipulation simplifications?

On Mon, Dec 04, 2006 at 02:40:05PM +0000, Mel Gorman wrote:
> On (02/12/06 13:15), Nick Piggin didst pronounce:
> > Hi,
> > 
> > While working in this area, I noticed a few things we do that may not
> > have a positive payoff under the most common conditions. Untested yet,
> > and probably needs a bit of instrumentation, but it saves about half a
> > K of code, lots of branches, and makes things look nicer. Any thoughts?
> > 
> > Quite a bit of code is used in maintaining these "cached pages" that are
> > probably pretty unlikely to get used.
> > 
> 
> I think you might be leaking now though. More comments below.
> 
> > Also, buffered write path (and others) uses its own LRU pagevec when we should
> > be just using the per-CPU LRU pagevec (which will cut down on both data and
> > code size cacheline footprint).
> > 
> 
> Splitting the patch into two could be nice but it's grand for the
> moment.

Hi Mel,

I think you're right about the leakage, thanks for catching it.

As far as allocating pages twice is concerned, I *strongly* believe
it is the wrong tradeoff to fix this with a "cached_page" because we
have to hit 2 reasonably rare races.

Firstly, we must find no pagecache exists, then we discover a page
has been installed after allocating. This will be rare for most
workloads, but lets say that it comes up in a few because page alloc
may sleep (a busy file server might have several processes reading
the same file, triggering this race in the write path would be even
less common).

However supposing this race is triggered, then we *also* need to
fail the page lookup a few instructions after a similar operation
has succeeded!

Thanks, will post an updated and properly tested version in a while.
-
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/