Re: [rfc] no ZERO_PAGE?

[Nick Piggin]

On Wed, Apr 04, 2007 at 10:45:39AM +0100, Hugh Dickins wrote:
> On Wed, 4 Apr 2007, Nick Piggin wrote:
> > On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
> > > 
> > > Well it would make life easier if we got rid of ZERO_PAGE completely,
> > > which I definitely wouldn't complain about ;)
> 
> Yes, I love this approach too.
> 
> > 
> > So, what bad things (apart from my bugs in untested code) happen
> > if we do this? We can actually go further, and probably remove the
> > ZERO_PAGE completely (just need an extra get_user_pages flag or
> > something for the core dumping issue).
> 
> Some things will go faster (no longer needing a separate COW fault
> on the read-protected ZERO_PAGE), some things will go slower and use
> more memory.  The open question is whether anyone will notice those
> regressions: I'm hoping they won't, I'm afraid they will.  And though
> we'll see each as a program doing "something stupid", as in the Altix
> case Robin showed to drive us here, we cannot just ignore it.

Sure. Agreed.

> > Shall I do a more complete patchset and ask Andrew to give it a
> > run in -mm?
> 
> I'd like you to: I didn't study the fragment below, it's really all
> uses of the ZERO_PAGE that I'd like to see go, then we see who shouts.

Yeah, they are basically pretty trivial to remove. I'll do a more
complete patch now that I know you like the approach.

> It's quite likely that the patch would have to be reverted: don't
> bother to remove the allocations of ZERO_PAGE in each architecture
> at this stage, too much nuisance going back and forth on those.

OK.

> Leave ZERO_PAGE as configurable, default off for testing, buried
> somewhere like under EMBEDDED?  It's much more attractive just to
> remove the old code, and reintroduce it if there's a demand; but
> leaving it under config would make it easy to restore, and if
> there's trouble with removing ZERO_PAGE, we might later choose
> to disable it at the high end but enable it at the low.  What
> would you prefer?

Ooh, the one with more '-' signs in the diff ;)

No, you have a point, but if we have to ask people to recompile 
with CONFIG_ZERO_PAGE, then it isn't much harder to ask them to
apply a patch first.

But for a potential mainline merge, maybe starting with a CONFIG
option is a good idea -- defaulting to off, and we could start by
turning it on just in -rc kernels for a few releases, to get a bit
more confidence?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/