From: Larry Woodman <lwoodman@redhat.com>
To: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Eric Whitney <eric.whitney@hp.com>,
Nick Dokos <nicholas.dokos@hp.com>
Subject: Re: [patch 00/19] VM pageout scalability improvements
Date: Fri, 04 Jan 2008 13:07:11 -0500 [thread overview]
Message-ID: <477E75CF.8070608@redhat.com> (raw)
In-Reply-To: <20080104115524.7d906f94@bree.surriel.com>
Rik van Riel wrote:
>On Fri, 04 Jan 2008 17:34:00 +0100
>Andi Kleen <andi@firstfloor.org> wrote:
>
>
>>Lee Schermerhorn <Lee.Schermerhorn@hp.com> writes:
>>
>>
>>
>>>We can easily [he says, glibly] reproduce the hang on the anon_vma lock
>>>
>>>
>>Is that a NUMA platform? On non x86? Perhaps you just need queued spinlocks?
>>
>>
>
>I really think that the anon_vma and i_mmap_lock spinlock hangs are
>due to the lack of queued spinlocks. Not because I have seen your
>system hang, but because I've seen one of Larry's test systems here
>hang in scary/amusing ways :)
>
Changing the anon_vma->lock into a rwlock_t helps because
page_lock_anon_vma()
can take it for read and thats where the contention is. However its the
fact that under
some tests, most of the pages are in vmas queued to one anon_vma that
causes so much
lock contention.
>
>With queued spinlocks the system should just slow down, not hang.
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Larry Woodman <lwoodman@redhat.com>
To: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>,
Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Eric Whitney <eric.whitney@hp.com>,
Nick Dokos <nicholas.dokos@hp.com>
Subject: Re: [patch 00/19] VM pageout scalability improvements
Date: Fri, 04 Jan 2008 13:07:11 -0500 [thread overview]
Message-ID: <477E75CF.8070608@redhat.com> (raw)
In-Reply-To: <20080104115524.7d906f94@bree.surriel.com>
Rik van Riel wrote:
>On Fri, 04 Jan 2008 17:34:00 +0100
>Andi Kleen <andi@firstfloor.org> wrote:
>
>
>>Lee Schermerhorn <Lee.Schermerhorn@hp.com> writes:
>>
>>
>>
>>>We can easily [he says, glibly] reproduce the hang on the anon_vma lock
>>>
>>>
>>Is that a NUMA platform? On non x86? Perhaps you just need queued spinlocks?
>>
>>
>
>I really think that the anon_vma and i_mmap_lock spinlock hangs are
>due to the lack of queued spinlocks. Not because I have seen your
>system hang, but because I've seen one of Larry's test systems here
>hang in scary/amusing ways :)
>
Changing the anon_vma->lock into a rwlock_t helps because
page_lock_anon_vma()
can take it for read and thats where the contention is. However its the
fact that under
some tests, most of the pages are in vmas queued to one anon_vma that
causes so much
lock contention.
>
>With queued spinlocks the system should just slow down, not hang.
>
>
>
--
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:[~2008-01-04 18:09 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-02 22:41 [patch 00/19] VM pageout scalability improvements linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 01/19] move isolate_lru_page() to vmscan.c linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 02/19] free swap space on swap-in/activation linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 03/19] define page_file_cache() function linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 04/19] debugging checks for page_file_cache() linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 05/19] Use an indexed array for LRU variables linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 06/19] split LRU lists into anon & file sets linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-07 9:23 ` KAMEZAWA Hiroyuki
2008-01-07 9:23 ` KAMEZAWA Hiroyuki
2008-01-02 22:41 ` [patch 07/19] split anon & file LRUs for memcontrol code linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-07 10:04 ` KAMEZAWA Hiroyuki
2008-01-07 10:04 ` KAMEZAWA Hiroyuki
2008-01-07 14:10 ` Balbir Singh
2008-01-07 14:10 ` Balbir Singh
2008-01-07 15:23 ` Rik van Riel
2008-01-07 15:23 ` Rik van Riel
2008-01-02 22:41 ` [patch 08/19] SEQ replacement for anonymous pages linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 09/19] add newly swapped in pages to the inactive list linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 10/19] No Reclaim LRU Infrastructure linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 11/19] Non-reclaimable page statistics linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 12/19] scan noreclaim list for reclaimable pages linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 13/19] ramfs pages are non-reclaimable linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 14/19] SHM_LOCKED pages are nonreclaimable linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:41 ` [patch 15/19] non-reclaimable mlocked pages linux-kernel
2008-01-02 22:41 ` linux-kernel
2008-01-02 22:42 ` [patch 16/19] mlock vma pages under mmap_sem held for read linux-kernel
2008-01-02 22:42 ` linux-kernel
2008-01-02 22:42 ` [patch 17/19] handle mlocked pages during map/unmap and truncate linux-kernel
2008-01-02 22:42 ` linux-kernel
2008-01-02 22:42 ` [patch 18/19] account mlocked pages linux-kernel
2008-01-02 22:42 ` linux-kernel
2008-01-02 22:42 ` [patch 19/19] cull non-reclaimable anon pages from the LRU at fault time linux-kernel
2008-01-02 22:42 ` linux-kernel
2008-01-02 23:17 ` [patch 00/19] VM pageout scalability - one big patch Rik van Riel
2008-01-03 3:44 ` [patch 00/19] VM pageout scalability improvements Rik van Riel
2008-01-10 2:39 ` Christoph Lameter
2008-01-10 3:14 ` Rik van Riel
2008-01-03 16:52 ` Lee Schermerhorn
2008-01-03 16:52 ` Lee Schermerhorn
2008-01-03 17:00 ` Rik van Riel
2008-01-03 17:00 ` Rik van Riel
2008-01-03 17:13 ` Lee Schermerhorn
2008-01-03 17:13 ` Lee Schermerhorn
2008-01-03 22:00 ` Rik van Riel
2008-01-03 22:00 ` Rik van Riel
2008-01-04 16:25 ` Lee Schermerhorn
2008-01-04 16:25 ` Lee Schermerhorn
2008-01-04 16:34 ` Andi Kleen
2008-01-04 16:34 ` Andi Kleen
2008-01-04 16:55 ` Rik van Riel
2008-01-04 16:55 ` Rik van Riel
2008-01-04 18:07 ` Larry Woodman [this message]
2008-01-04 18:07 ` Larry Woodman
2008-01-04 17:06 ` Lee Schermerhorn
2008-01-04 17:06 ` Lee Schermerhorn
2008-01-07 19:07 ` Christoph Lameter
2008-01-07 19:07 ` Christoph Lameter
2008-01-07 19:32 ` Rik van Riel
2008-01-07 19:32 ` Rik van Riel
2008-01-07 10:06 ` KAMEZAWA Hiroyuki
2008-01-07 10:06 ` KAMEZAWA Hiroyuki
2008-01-07 15:18 ` Rik van Riel
2008-01-07 15:18 ` Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2008-01-08 20:59 Rik van Riel
2008-01-08 20:59 ` Rik van Riel
2008-01-10 4:39 ` Mike Snitzer
2008-01-10 4:39 ` Mike Snitzer
2008-01-10 15:41 ` Rik van Riel
2008-01-10 15:41 ` Rik van Riel
2008-01-10 16:08 ` Mike Snitzer
2008-01-10 16:08 ` Mike Snitzer
2008-01-11 10:41 ` Balbir Singh
2008-01-11 10:41 ` Balbir Singh
2008-01-11 15:38 ` Rik van Riel
2008-01-11 15:38 ` Rik van Riel
2008-01-11 11:47 ` Balbir Singh
2008-01-11 11:47 ` Balbir Singh
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=477E75CF.8070608@redhat.com \
--to=lwoodman@redhat.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=andi@firstfloor.org \
--cc=eric.whitney@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nicholas.dokos@hp.com \
--cc=riel@redhat.com \
/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.