All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
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 23:09:19 +0100	[thread overview]
Message-ID: <1257890959.4108.496.camel@laptop> (raw)
In-Reply-To: <Pine.LNX.4.64.0911102200480.2816@sister.anvils>

On Tue, 2009-11-10 at 22:02 +0000, Hugh Dickins wrote:
> CONFIG_DEBUG_SPINLOCK adds 12 or 16 bytes to a 32- or 64-bit spinlock_t,
> and CONFIG_DEBUG_LOCK_ALLOC adds another 12 or 24 bytes to it: lockdep
> enables both of those, and CONFIG_LOCK_STAT adds 8 or 16 bytes to that.
> 
> When 2.6.15 placed the split page table lock inside struct page (usually
> sized 32 or 56 bytes), only CONFIG_DEBUG_SPINLOCK was a possibility, and
> we ignored the enlargement (but fitted in CONFIG_GENERIC_LOCKBREAK's 4
> by letting the spinlock_t occupy both page->private and page->mapping).
> 
> Should these debugging options be allowed to double the size of a struct
> page, when only one minority use of the page (as a page table) needs to
> fit a spinlock in there?  Perhaps not.
> 
> 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.

> Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
> ---
> 
>  mm/Kconfig |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> --- mm4/mm/Kconfig	2009-11-04 10:52:58.000000000 +0000
> +++ mm5/mm/Kconfig	2009-11-04 10:53:13.000000000 +0000
> @@ -161,11 +161,13 @@ config PAGEFLAGS_EXTENDED
>  # Default to 4 for wider testing, though 8 might be more appropriate.
>  # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
>  # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
> +# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
>  #
>  config SPLIT_PTLOCK_CPUS
>  	int
> -	default "4096" if ARM && !CPU_CACHE_VIPT
> -	default "4096" if PARISC && !PA20
> +	default "999999" if ARM && !CPU_CACHE_VIPT
> +	default "999999" if PARISC && !PA20
> +	default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC
>  	default "4"
>  
>  #



WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Hugh Dickins <hugh.dickins@tiscali.co.uk>
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 23:09:19 +0100	[thread overview]
Message-ID: <1257890959.4108.496.camel@laptop> (raw)
In-Reply-To: <Pine.LNX.4.64.0911102200480.2816@sister.anvils>

On Tue, 2009-11-10 at 22:02 +0000, Hugh Dickins wrote:
> CONFIG_DEBUG_SPINLOCK adds 12 or 16 bytes to a 32- or 64-bit spinlock_t,
> and CONFIG_DEBUG_LOCK_ALLOC adds another 12 or 24 bytes to it: lockdep
> enables both of those, and CONFIG_LOCK_STAT adds 8 or 16 bytes to that.
> 
> When 2.6.15 placed the split page table lock inside struct page (usually
> sized 32 or 56 bytes), only CONFIG_DEBUG_SPINLOCK was a possibility, and
> we ignored the enlargement (but fitted in CONFIG_GENERIC_LOCKBREAK's 4
> by letting the spinlock_t occupy both page->private and page->mapping).
> 
> Should these debugging options be allowed to double the size of a struct
> page, when only one minority use of the page (as a page table) needs to
> fit a spinlock in there?  Perhaps not.
> 
> 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.

> Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
> ---
> 
>  mm/Kconfig |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> --- mm4/mm/Kconfig	2009-11-04 10:52:58.000000000 +0000
> +++ mm5/mm/Kconfig	2009-11-04 10:53:13.000000000 +0000
> @@ -161,11 +161,13 @@ config PAGEFLAGS_EXTENDED
>  # Default to 4 for wider testing, though 8 might be more appropriate.
>  # ARM's adjust_pte (unused if VIPT) depends on mm-wide page_table_lock.
>  # PA-RISC 7xxx's spinlock_t would enlarge struct page from 32 to 44 bytes.
> +# DEBUG_SPINLOCK and DEBUG_LOCK_ALLOC spinlock_t also enlarge struct page.
>  #
>  config SPLIT_PTLOCK_CPUS
>  	int
> -	default "4096" if ARM && !CPU_CACHE_VIPT
> -	default "4096" if PARISC && !PA20
> +	default "999999" if ARM && !CPU_CACHE_VIPT
> +	default "999999" if PARISC && !PA20
> +	default "999999" if DEBUG_SPINLOCK || DEBUG_LOCK_ALLOC
>  	default "4"
>  
>  #


--
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:09 UTC|newest]

Thread overview: 62+ 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:50 ` Hugh Dickins
2009-11-10 21:51 ` [PATCH 1/6] mm: define PAGE_MAPPING_FLAGS Hugh Dickins
2009-11-10 21:51   ` Hugh Dickins
2009-11-19  0:25   ` Rik van Riel
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-10 21:55   ` Hugh Dickins
2009-11-11  7:56   ` KOSAKI Motohiro
2009-11-11  7:56     ` KOSAKI Motohiro
2009-11-11 11:36     ` Hugh Dickins
2009-11-11 11:36       ` Hugh Dickins
2009-11-13  8:16       ` KOSAKI Motohiro
2009-11-13  8:16         ` KOSAKI Motohiro
2009-11-13  8:26         ` KOSAKI Motohiro
2009-11-13  8:26           ` KOSAKI Motohiro
2009-11-13 11:50           ` Andrea Arcangeli
2009-11-13 11:50             ` Andrea Arcangeli
2009-11-13 18:00             ` KOSAKI Motohiro
2009-11-13 18:00               ` KOSAKI Motohiro
2009-11-15 22:37         ` Hugh Dickins
2009-11-15 22:37           ` Hugh Dickins
2009-11-17  2:00           ` KOSAKI Motohiro
2009-11-17  2:00             ` KOSAKI Motohiro
2009-11-18 16:32             ` Hugh Dickins
2009-11-18 16:32               ` Hugh Dickins
2009-11-13  6:30   ` KOSAKI Motohiro
2009-11-13  6:30     ` KOSAKI Motohiro
2009-11-15 22:16     ` Hugh Dickins
2009-11-15 22:16       ` Hugh Dickins
2009-11-16 23:34       ` KOSAKI Motohiro
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-10 21:59   ` Hugh Dickins
2009-11-11  1:22   ` KOSAKI Motohiro
2009-11-11  1:22     ` KOSAKI Motohiro
2009-11-11 10:48     ` Hugh Dickins
2009-11-11 10:48       ` Hugh Dickins
2009-11-11 12:38   ` Andi Kleen
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:00   ` Hugh Dickins
2009-11-10 22:02 ` [PATCH 5/6] mm: stop ptlock enlarging struct page Hugh Dickins
2009-11-10 22:02   ` Hugh Dickins
2009-11-10 22:09   ` Peter Zijlstra [this message]
2009-11-10 22:09     ` Peter Zijlstra
2009-11-10 22:24     ` Hugh Dickins
2009-11-10 22:24       ` Hugh Dickins
2009-11-10 22:14   ` Peter Zijlstra
2009-11-10 22:14     ` Peter Zijlstra
2009-11-10 22:29     ` Hugh Dickins
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-10 22:06   ` Hugh Dickins
2009-11-11  2:37   ` KAMEZAWA Hiroyuki
2009-11-11  2:37     ` KAMEZAWA Hiroyuki
2009-11-11  2:42     ` KOSAKI Motohiro
2009-11-11  2:42       ` KOSAKI Motohiro
2009-11-11  4:35       ` Wu Fengguang
2009-11-11  4:35         ` Wu Fengguang
2009-11-11  5:51   ` Minchan Kim
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=1257890959.4108.496.camel@laptop \
    --to=peterz@infradead.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=ieidus@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.