[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070427134451.GP19966@holomorphy.com>
Date: Fri, 27 Apr 2007 06:44:51 -0700
From: William Lee Irwin III <wli@...omorphy.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Lameter <clameter@....com>, David Chinner <dgc@....com>,
linux-kernel@...r.kernel.org, Mel Gorman <mel@...net.ie>,
Jens Axboe <jens.axboe@...cle.com>,
Badari Pulavarty <pbadari@...il.com>,
Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3
On Thu, Apr 26, 2007 at 11:55:42PM -0700, Andrew Morton wrote:
> Please address my point: if in five years time x86 has larger or varible
> pagesize, this code will be a permanent millstone around our necks which we
> *should not have merged*.
> And if in five years time x86 does not have larger pagesize support then
> the manufacturers would have decided that 4k pages are not a performance
> problem, so we again should not have merged this code.
So the verdict is wait 5 years, see if x86 did anything, and so on.
Has anyone else noticed our embedded arch installed base dwarfs our
x86 and "enterprise" installed bases combined? What are our priorities
that make designing the core around x86 meaningful again? Pipe dreams
of competing with Windows on the desktop? Optimizing for kernel
compiles on kernel hackers' workstations? Something should seriously
be reevaluated there at some point.
As x86 is now the priority regardless, maybe checking in with Intel and
AMD as far as what they'd like to see happen would be enlightening. It
may be that some things are deadlocked on OS use cases.
Also, is there something in particular that should be done for the case
of x86 acquiring a variable pagesize?
-- 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