ppc64 oops..

[Nick Piggin]

Linus Torvalds wrote:

>>I'm hankering to back out the whole thing - it just has too many 
>>problems for now.  But Hugh's busily working on things and I thought it 
>>best to leave it a couple of days until he has a verdict.
> 

Been away for a couple of days and I'm still not caught up with
things. Luckily this thing is looking more like a ppc64 bug, however
I'll be watching this space to see if I can be of any use...

> 
> Yeah. I'll give up for today, and look at it tomorrow. 
> 
> I think getting rid of PageReserved() was the right thing from a page 
> table traversal standpoint: every time I see a code-path that removes a 
> check for PageReserved() and replaces it with a VM_IO check or similar, it 
> looks fine.
> 
> I just think that people went too far in thinking that PageReserved itself 
> was somehow wrong. It's great for the Zero page, and it's great for kernel 
> pages in general (and things like the ISA hole on x86).
> 

I think it was really weird and conducive of bugs that PageReserved
for some ungodly reason would turn put_page into a noop. I'm sure it
was a hack when it was put in, and it IMO it was always a hack.

Not to mention other side effects like preventing the page from being
saved by swsusp, or exempting its user mappings from rmap accounting.

I really don't think we've missed PG_reserved. The ZERO_PAGE accounting
thing may be a problem, but that problem didn't come about due to
removal of PageReserved, but rather the concurrent removal of ZERO_PAGE
special casing we had there - it can be reinstated (and a solution for
2.6.15 won't be difficult).

If we end up needing something like say, PG_zero for per-node zero
pages then I would not be against the flag at all, so long as it had
well defined semantics.

-- 
SUSE Labs, Novell Inc.


Send instant messages to your online friends http://au.messenger.yahoo.com