Re: [rfc] no ZERO_PAGE?

[Hugh Dickins]

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.

> 
> 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.

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.

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?

Hugh
-
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/