Re: [PATCH] resolve duplicate flag no for PG_lazyfree

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

Andrew Morton wrote:
> On Mon, 14 May 2007 14:06:19 -0400
> Theodore Tso <tytso@mit.edu> wrote:
> 
> 
>>On Sun, May 13, 2007 at 10:46:30PM -0700, Andrew Morton wrote:
>>
>>>otoh, the intersection between pages which are PageBooked() and pages which
>>>are PageLazyFree() should be zreo, so it'd be good to actually formalise
>>>this reuse within the ext4 patches.
>>>
>>>otoh2, PageLazyFree() could have reused PG_owner_priv_1.
>>>
>>>Rik, Ted: any thoughts?  We do need to scrimp on page flags: when we
>>>finally run out, we're screwed.
>>
>>It makes sense to me.  PG_lazyfree is currently only in -mm, right?
> 
> 
> Ah, yes, I got confused, sorry.
> 
> 
>> I
>>don't see it in my git tree.  It would probably would be a good idea
>>to make sure that we check to add some sanity checking code if it
>>isn't there already that PG_lazyfree isn't already set when try to set
>>PG_lazyfree (just in case there is a bug in the future which causes
>>the should-never-happen case of trying lazy free a PageBooked page).
>>
> 
> 
> Actually, I think the current status of
> lazy-freeing-of-memory-through-madv_free.patch is "might not be needed".  I
> _think_ we've determined that 0a27a14a62921b438bb6f33772690d345a089be6
> sufficiently fixed the perfomance problems we had in there?

I think so far we've found that it fixes the MySQL scalability problem,
yes. I couldn't see any statistically significant difference with MySQL
in my tests with MADV_FREE (versus MADV_DONTNEED).

ebizzy is improved a bit at low concurrency but drops off slightly at
higher concurrency.

But basically, I don't think we've found a good reason to use a page
flag and introduce the potential performance regressions that the
MADV_FREE patch has.

-- 
SUSE Labs, Novell Inc.