Re: [RFC][patch 0/2] mm: remove PageReserved

[Nick Piggin <nickpiggin@yahoo.com.au>]

Daniel Phillips wrote:
> On Sunday 07 August 2005 13:28, Nick Piggin wrote:

> > If anyone has an issue with the patches or my merge plan, let's
> > get some discussion going.
>
>
> You forgot to mention what replaces PageReserved: the VM_RESERVED vma flag, 
> which is now added to the whole zap_pte call chain.  A slight efficiency win?  
> Anyway, it looks like forward progress because some inner loops are a little 
> straighter.  I've always wondered what PG_reserved was actually doing, and 
> now I know: compensating for the missing vma parameter in the zap call 
> chains.

Basically, it was doing a whole lot of vaguely related things. It
was set for ZERO_PAGE pages. It was (and still is) set for struct
pages that don't point to valid ram. Drivers set it, hoping it will
do something magical for them.

And yes, the VM_RESERVED flag is able to replace most usages.
Checking (pte_page(pte) == ZERO_PAGE(addr)) picks up others.

What we don't have is something to indicate the page does not point
to valid ram.

> Why don't you pass the vma in zap_details?  For that matter, why are addr and 
> end still passed down the zap chain when zap_details appears to duplicate 
> that information?  OK, it is because zap_details is NULL in about twice as 
> many places as it carries data.  But since the details parameter is already 
> there, would it not make sense to press it into service to slim down those 
> parameter lists a little?

Possibly. I initially did it that way, but it ended up fattening
paths that don't use details. And this way is less intrusive.

> What stops swsusp from also using the vma flag?  Why does swsusp need both 
> PG_reserved and PG_nosave?

Because swsusp isn't looking through a process mapping.

swsusp also uses PG_nosave_free, believe it or not. Though I think
PG_nosave and PG_nosave_free can be consolidated quite easily.

> Is there automated testing planned for this one?  It looks right as closely as 
> I've read, but it tickles an awful lot of code.

I haven't planned anything. I've tested it on machines here,
but I should probably do so a bit more heavily (ie. thrashing
swap, reclaiming pagecache, etc for hours).

Thanks for having a look!

Nick

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/