[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