RFC: Page size on PPC/PPC64 builders

David Woodhouse dwmw2 at infradead.org
Tue Mar 4 17:51:22 UTC 2008


On Tue, 2008-03-04 at 09:59 +0100, Jim Meyering wrote:
> David Woodhouse <dwmw2 at infradead.org> wrote:
> > I'm concerned that switching back to 4KiB pages is just papering over
> > real bugs to make life easier for PPC folks. I suspect that what I
> > should _actually_ do is keep it 64KiB, brazen it out and LART people who
> > just exclude ppc builds without actually looking at the problem for
> > themselves. But I'm lazy too... maybe we should switch the x86_64
> > builders to 64KiB instead? :)
> >
> > Opinions?
> 
> I'm surprised there's so much debate.
> Isn't it obvious?  A service that finds generic bugs -- and ones
> that would likely be much harder to diagnose in any other context.
> People will complain no matter what you do, so take the high road:
> 
> Brazen it out with a LART :-)

The problem is that there is a risk that it'll make the less
conscientious packagers just think 'oh, building for ppc is painful' and
exclude that architecture. There's enough of that already, with some
people even sticking to that line even after the same bug bites them on
x86_64 too.

That's not _such_ an issue because there are relatively few such
packagers, and we have the rule that all architecture exclusions _must_
be filed in bugzilla and we can keep track of them through the
ExcludeArch tracker bugs.

My _real_ concern is that continuing to use 64KiB pages is likely to
increase the motivation for people to let PPC builds fail _without_
aborting the main build on x86/x86_64, so the laziest of packagers don't
even have to _look_ when their build fails. And then a lot of the
benefit is lost (or we just start pushing even more of the generic bugs
onto the arch team and making it really hard for them to keep in sync
with the development tree properly).

Yes, that would be extremely misguided, but I think it's dangerously
likely to happen and I don't want to make it _more_ likely or accelerate
it.

-- 
dwmw2




More information about the fedora-devel-list mailing list