[PATCH V2 0/5] Huge pages for short descriptors on ARM
Russell King - ARM Linux
linux at arm.linux.org.uk
Thu Apr 24 04:03:21 PDT 2014
On Thu, Apr 24, 2014 at 11:55:56AM +0100, Steve Capper wrote:
> On 24 April 2014 11:42, Russell King - ARM Linux <linux at arm.linux.org.uk> wrote:
> > On Thu, Apr 24, 2014 at 11:36:39AM +0100, Will Deacon wrote:
> >> I guess I'm after some commitment that this is (a) useful to somebody and
> >> (b) going to be tested regularly, otherwise it will go the way of things
> >> like big-endian, where we end up carrying around code which is broken more
> >> often than not (although big-endian is more self-contained).
> >
> > It may be something worth considering adding to my nightly builder/boot
> > testing, but I suspect that's impractical as it probably requires a BE
> > userspace, which would then mean that the platform can't boot LE.
> >
> > I suspect that we will just have to rely on BE users staying around and
> > reporting problems when they occur.
>
> The huge page support is for standard LE, I think Will was saying that
> this will be like BE if no-one uses it.
We're not saying that.
What we're asking is this: *Who* is using hugepages today?
What we're then doing is comparing it to the situation we have today with
BE, where BE support is *always* getting broken because no one in the main
community tests it - not even a build test, nor a boot test which would
be required to find the problems that (for example) cropped up in the
last merge window.
> It's somewhat unfair to compare huge pages on short descriptors with
> BE. For a start, the userspace that works with LPAE will work on the
> short-descriptor kernel too.
That sounds good, but the question is how does this get tested by
facilities such as my build/boot system, or Olof/Kevin's system?
Without that, it will find itself in exactly the same situation that
BE is in, where problems aren't found until after updates are merged
into Linus' tree.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
More information about the linux-arm-kernel
mailing list