linux-kernel - Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE

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: <1184335711.15479.39.camel@kleikamp.austin.ibm.com>
Date:	Fri, 13 Jul 2007 09:08:31 -0500
From:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
To:	David Chinner <dgc@....com>
Cc:	haveblue@...ux.vnet.ibm.com, Andrea Arcangeli <andrea@...e.de>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)

On Fri, 2007-07-13 at 17:13 +1000, David Chinner wrote:
> On Thu, Jul 12, 2007 at 09:34:57AM -0700, Dave Hansen wrote:
> > On Thu, 2007-07-12 at 18:31 +0200, Andrea Arcangeli wrote:
> > > On Fri, Jul 13, 2007 at 12:44:49AM +1000, David Chinner wrote:
> > > > That's crap. Just because a machine has lots of memory does not
> > > > make it OK to waste lots of memory.
> > > 
> > > It's not just wasted, it lowers overhead all over the place. Yes, the
> > > benefit of wasting less pagecache may largely outweight the benefit of
> > > having a larger page size, but if you've a lot of memory perhaps your
> > > working set already fits in the cache, or perhaps you don't fit in the
> > > cache regardless of the page size.
> > 
> > Have you guys seen Shaggy's page cache tails?
> > 
> > http://kernel.org/pub/linux/kernel/people/shaggy/OLS-2006/kleikamp.pdf
> > 
> > We've had the same memory waste issue on ppc64 with 64k hardware
> > pages.  
> 
> Sure. Fundamentally, though, I think it is the wrong approach to
> take - it's a workaround for a big negative side effect of
> increasing page size. It introduces lots of complexity and
> difficult-to-test corner cases; judging by the tail packing problems
> reiser3 has had over the years, it has the potential to be a
> never-ending source of data corruption bugs.

Yeah, I'm not real happy right now with the complexity of my patches.  I
had some hope that Christoph's variable page cache cleanups would
simplify some of it, but that doesn't really help.  I'm working on it
though.

> I think that fine granularity and aggregation for efficiency of
> scale is a better model to use than increasing the base page size.
> With PPC, you can handle different page sizes in the hardware (like
> MIPS) and the use of 64k base page size is an obvious workaround to
> the problem of not being able to use multiple page sizes within the
> OS.
> 
> Adding a workaround (tail packing) to address the negative side
> effects of another workaround (64k base page size) ignores the basic
> problem that has led to both these things being done: Linux does not
> support multiple page sizes natively.....

I'd much prefer having support for multiple page sizes.  I have to admit
that I don't know the VM well enough to weigh in on that debate.

Thanks,
Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
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/