Re: [patch][rfc] remove ZERO_PAGE?

Linus Torvalds
2007-07-30T03:45:25Z

On Mon, 30 Jul 2007, Nick Piggin wrote:
>
> Well the issue wasn't exactly that, but the fact that a lot of processes
> all exitted at once, while each having a significant number of ZERO_PAGE
> mappings. The freeing rate ends up going right down (OK it wasn't quite a
> livelock, finishing in > 2 hours, but without ZERO_PAGE bouncing they
> exit in 5 seconds).

Umm. Isn't this because of the new page->mapping counting for reserved
pages?

The one I was violently against, and told you (and Hugh) was pointless and
bad?

Or what "bouncing" are you talking about?

In other words, this doesn't really sound like a ZERO_PAGE problem at all,
but a problem that was engineered by unnecessarily trying to count those
pages in the first place. No?

> > Kernel builds with/without this? If the page faults really are that big a
> > deal, this should all be visible.
>
> Sorry if it was misleading: the kernel build numbers weren't really about
> where ZERO_PAGE hurts us, but just trying to show that it doesn't help too
> much (for which I realise anything short of a kernel.org release is sadly
> inadequate).
>
> Anyway, I'll see if I can get anything significant...

The thing that really riles me up about this is that the whole damn thing
seems to be so pointless. This "ZERO_PAGE is bad" thing has been a
constant background noise, where people are pushing their opinions with no
real technical reasons.

I want technical reasons, but I get the feeling that this pogrom is abotu
anything but technical arguments.

So I _really_ don't want to hear you blaming ZERO_PAGE for something that
you introduced yourself with Hugh, and that had _zero_ to do with
ZERO_PAGE, and that I spent weeks saying was pointless, to the point where
I just gave up.

Now, that you apparently have found the perfect load that proved me right,
you instead of blaming the pointless refcounting, you want to blame the
poor ZERO_PAGE. Again.

And THAT is what makes me irritated with this patch. I hate the
background, and what looks like intellectual dishonesty. I _told_ people
that refcounting reserved pages was pointless and bad. Did you listen? No.
And now that it causes problems, rather than blame the refcounting, you
blame the victim.

The zero page is *cheaper* to set up than normal pages. It always was. You
just *made* it more expensive, because of the irrational fear of
PageReserved() that protected us from all those unnecessary bounces in the
first place.

So a totally equivalent fix would be to just re-instate the PageReserved
checks. It would likely even be easier these days (one logical place to do
so would be in "vm_normal_page()", which automatically would catch all
unmapping cases, but you'd still have to make sure you don't *increment*
the page count when you map it too, of course).

But if you can actually show that ZERO_PAGE literally slows things down
(and none of this page count bouncing crud that you were the one that
introduced in the first place), then _that_ would be a totally different
issue. At that point, you have an independent reason for removing code
that has basically been there since day 1, and all my arguments go away.

See?

I'd love to hear "here's a real-life load, and yes, the ZERO_PAGE logic
really does hurt more than it helps, it's time to remove it". At that
point I'll happily apply the patch.

But what I *don't* want to hear is "we screwed up the reference-counting
of ZERO_PAGE, so now it's so expensive that we want to remove the page
entirely". That just makes me sad. And a bit angry.

Linus