linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hugh Dickins <hugh.dickins@tiscali.co.uk>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Izik Eidus <ieidus@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 5/6] mm: stop ptlock enlarging struct page
Date: Tue, 10 Nov 2009 22:24:18 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0911102214550.6355@sister.anvils> (raw)
In-Reply-To: <1257890959.4108.496.camel@laptop>

On Tue, 10 Nov 2009, Peter Zijlstra wrote:
> On Tue, 2009-11-10 at 22:02 +0000, Hugh Dickins wrote:
> > 
> > Take the easy way out: switch off SPLIT_PTLOCK_CPUS when DEBUG_SPINLOCK
> > or DEBUG_LOCK_ALLOC is in force.  I've sometimes tried to be cleverer,
> > kmallocing a cacheline for the spinlock when it doesn't fit, but given
> > up each time.  Falling back to mm->page_table_lock (as we do when ptlock
> > is not split) lets lockdep check out the strictest path anyway.
> 
> Why? we know lockdep bloats stuff we never cared.. and hiding a popular
> CONFIG option from lockdep doesn't seem like a good idea to me.

That's a fair opinion, and indeed I Cc'ed you in case it were yours.

I'd like to see how other people feel about it.  Personally I detest
and regret that bloat to struct page, when there's only one particular
use of a page that remotely excuses it.

If it were less tiresome, I'd have gone for the dynamic kmalloc; but
it seemed silly to make that effort when the Kconfig mod is so easy.

But so far as letting lockdep do its job goes, we're actually better
off using page_table_lock there, as I tried to explain: since that
lock is used for a few other purposes, lockdep is more likely to
catch an issue which the SPLIT_PTLOCK case could be hiding.

Hugh

--
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>

  reply	other threads:[~2009-11-10 22:24 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-10 21:50 [PATCH 0/6] mm: prepare for ksm swapping Hugh Dickins
2009-11-10 21:51 ` [PATCH 1/6] mm: define PAGE_MAPPING_FLAGS Hugh Dickins
2009-11-19  0:25   ` Rik van Riel
2009-11-10 21:55 ` [PATCH 2/6] mm: mlocking in try_to_unmap_one Hugh Dickins
2009-11-11  7:56   ` KOSAKI Motohiro
2009-11-11 11:36     ` Hugh Dickins
2009-11-13  8:16       ` KOSAKI Motohiro
2009-11-13  8:26         ` KOSAKI Motohiro
2009-11-13 11:50           ` Andrea Arcangeli
2009-11-13 18:00             ` KOSAKI Motohiro
2009-11-15 22:37         ` Hugh Dickins
2009-11-17  2:00           ` KOSAKI Motohiro
2009-11-18 16:32             ` Hugh Dickins
2009-11-13  6:30   ` KOSAKI Motohiro
2009-11-15 22:16     ` Hugh Dickins
2009-11-16 23:34       ` KOSAKI Motohiro
2009-11-10 21:59 ` [PATCH 3/6] mm: CONFIG_MMU for PG_mlocked Hugh Dickins
2009-11-11  1:22   ` KOSAKI Motohiro
2009-11-11 10:48     ` Hugh Dickins
2009-11-11 12:38   ` Andi Kleen
2009-11-10 22:00 ` [PATCH 4/6] mm: pass address down to rmap ones Hugh Dickins
2009-11-10 22:02 ` [PATCH 5/6] mm: stop ptlock enlarging struct page Hugh Dickins
2009-11-10 22:09   ` Peter Zijlstra
2009-11-10 22:24     ` Hugh Dickins [this message]
2009-11-10 22:14   ` Peter Zijlstra
2009-11-10 22:29     ` Hugh Dickins
2009-11-10 22:06 ` [PATCH 6/6] mm: sigbus instead of abusing oom Hugh Dickins
2009-11-11  2:37   ` KAMEZAWA Hiroyuki
2009-11-11  2:42     ` KOSAKI Motohiro
2009-11-11  4:35       ` Wu Fengguang
2009-11-11  5:51   ` Minchan Kim

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=Pine.LNX.4.64.0911102214550.6355@sister.anvils \
    --to=hugh.dickins@tiscali.co.uk \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=ieidus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.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