linux-kernel - Re: [PATCH] resolve duplicate flag no for PG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <464A501A.3080209@yahoo.com.au>
Date:	Wed, 16 May 2007 10:28:10 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Theodore Tso <tytso@....edu>,
	Fengguang Wu <fengguang.wu@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Rik van Riel <riel@...hat.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] resolve duplicate flag no for PG_lazyfree

Andrew Morton wrote:
> On Mon, 14 May 2007 14:06:19 -0400
> Theodore Tso <tytso@....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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/