From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrew Morton <akpm@osdl.org>, Hugh Dickins <hugh@veritas.com>,
Linux Memory Management <linux-mm@kvack.org>,
Christoph Lameter <clameter@sgi.com>
Subject: Re: [patch][rfc] possible lock_page fix for Andrea's nopage vs invalidate race?
Date: Wed, 02 Aug 2006 10:19:11 +1000 [thread overview]
Message-ID: <44CFEF7F.1070209@yahoo.com.au> (raw)
In-Reply-To: <20060801142749.GC6455@opteron.random>
Andrea Arcangeli wrote:
> On Tue, Aug 01, 2006 at 09:36:23PM +1000, Nick Piggin wrote:
>>I suppose we should think about fixing it some day?
>
>
> I was thinking about this every few days too, but I already submitted
> two fixes and I got somewhat contradictory reviews of them, so I
> wasn't sure what to do given that for mainline it's mostly a DoS
> because the VM lacks the proper bugchecks in the objrmap layer to
> autodetect the leak (the bugchecks I'm talking about only exists only
> in the sles9 VM, Hugh removed them while merging objrmap into
> mainline, and the fact they existed in sles9 is why we noticed and
> tracked down this leak). We already fixed the bug in sles9 a while ago
> with my second fix, but I obviously agree we have to fix it in
> mainline as well some day too, infact I wouldn't mind to add the
> bugchecks too to be sure something like this doesn't go unnoticed
> again (especially now that in sles10 we're in VM sync with mainline).
Well, I don't think it would be out of the question to add bug checks
for obscure conditions if they might have actually detected bugs for
us. It is common to see bug fixes also adding a BUG_ON to ensure similar
problems or future regressions are noticed. I can't remember Hugh's
reason for not wanting the check there, though.
>
> I really appreciate this third way being implemented. It looks quite
> nice. Great work.
Thanks, glad you like it :)
Hugh did mention a 2% slowdown in lmbench tests due to the lock page
(but maybe that was before removing the truncate_count stuff?). That
isn't good, but it actually seems to speed up kbuild (which is very
do_no_page intensive). I didn't get enough samples to be statistically
significant, but it looks like 1s speedup on shmfs, and 3/4s on ext3.
So if the lmbench slowdown is still there, I think kbuild trumps it.
However, my testing is just on a P4, so it would be good to check a
wider range of architectures too. I'll spend a bit of time with that
when I get a chance.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-08-02 0:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-01 11:36 Nick Piggin
2006-08-01 14:27 ` Andrea Arcangeli
2006-08-02 0:19 ` Nick Piggin [this message]
2006-08-03 16:04 ` Hugh Dickins
2006-08-05 3:52 ` Nick Piggin
2006-08-07 14:18 ` Nick Piggin
2006-08-07 14:58 ` Nick Piggin
2006-08-07 15:25 ` Hugh Dickins
2006-08-08 1:17 ` Nick Piggin
2006-08-07 17:05 ` Hugh Dickins
2006-08-08 1:14 ` Nick Piggin
2006-08-08 18:19 ` Hugh Dickins
2006-08-03 16:34 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44CFEF7F.1070209@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=andrea@suse.de \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox