Message-ID: <20070420062215.GE31925@holomorphy.com>
Date:	Thu, 19 Apr 2007 23:22:15 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Christoph Lameter <clameter@....com>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Paul Jackson <pj@....com>, Dave Chinner <dgc@....com>,
	Andi Kleen <ak@...e.de>
Subject: Re: [RFC 0/8] Variable Order Page Cache

On Thu, 19 Apr 2007, William Lee Irwin III wrote:
>> Oh dear. Per-file pagesizes are foul. Better to fix up the pagecache's
>> radix tree than to restrict it like this. There are other attacks on the
>> multiple horizontal internal tree node allocation problem beyond
>> outright B+ trees that allow radix trees to continue to be used.

On Thu, Apr 19, 2007 at 10:27:34PM -0700, Christoph Lameter wrote:
> per-file pagesizes are just the granularity that is available. The order
> value is then readily available for all page cache operations. In practice 
> it is likely that filesystems will have one consistent page size. If you 
> look at the ramfs implementation then you will see that is exactly the
> approach taken here. I want to avoid any modifications to key data 
> structures or locking. If possible straight code transformation.

I'm not sure how to say this politely, so please don't take it as a
slight. Hacks to avoid diffsize increases that would result from data
structure code are highly specious. There are typically functionality
or efficiency issues deliberately left unaddressed to accomplish such.
When committing the patch, you generally end up implicitly committed
to later updates to address those issues.

That said, even if some maintainers consciously agree (it's actually
rather clear that my opinion here is not representative of the majority
if anyone else at all), it does still present an issue for "marketing"
patches since diffsize is so easily latched onto as a metric of risk.

Don't worry about it for now. This will do fine.


On Thu, 19 Apr 2007, William Lee Irwin III wrote:
>> I've always wanted the awareness to be pervasive, so it's good to hear
>> there's someone with a common interest. If this effort takes off, I'd be
>> happy to contribute to it. I do wonder what ever happened with the gelato
>> codebase, though.

On Thu, Apr 19, 2007 at 10:27:34PM -0700, Christoph Lameter wrote:
> The superpages? I do not think that we should be getting that complicated 
> here. Maybe we can pick up some ideas at some point.

They're all TLB so picking things up on the TLB side can be done there.
I think they also keep the long format VHPT code updated to recent
mainline, which makes higher-order pages meaningful on ia64 (which with
the region register -based affair they are effectively not).


On Thu, 19 Apr 2007, William Lee Irwin III wrote:
>> I'm afraid this may be approaching an underappreciated research topic.
>> Most sponsors of such research seem to have an active disinterest in
>> getting page replacement to properly interoperate with all this.

On Thu, Apr 19, 2007 at 10:27:34PM -0700, Christoph Lameter wrote:
> Well that is the difference between academia where one gets his Ph.D. for
> superpages, publishes a couple of papers and then its over and real 
> kernel work where this actually will have to work consistently with the 
> rest of the system. Let us thus do small steps towards the goal 
> while keeping things as simple and straightforward as possible.

A more careful reading would reveal this as a criticism of industrial
sponsorship of research, not academia per se. For instance, what IHV
would bother sponsoring research on page replacement, since when
grinding out [trademarked name of major benchmark censored] numbers to
sell their systems, they arrange for page replacement never to happen?


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

Powered by blists - more mailing lists