From: Tim Chen <tim.c.chen@linux.intel.com>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@suse.de>, "Shi, Alex" <alex.shi@intel.com>,
Andi Kleen <andi@firstfloor.org>,
Andrew Morton <akpm@linux-foundation.org>,
Michel Lespinasse <walken@google.com>,
Davidlohr Bueso <davidlohr.bueso@hp.com>,
"Wilcox, Matthew R" <matthew.r.wilcox@intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Rik van Riel <riel@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm <linux-mm@kvack.org>
Subject: Re: Performance regression from switching lock to rw-sem for anon-vma tree
Date: Tue, 06 Aug 2013 17:56:28 -0700 [thread overview]
Message-ID: <1375836988.22432.435.camel@schen9-DESK> (raw)
In-Reply-To: <1375833325.2134.36.camel@buesod1.americas.hpqcorp.net>
On Tue, 2013-08-06 at 16:55 -0700, Davidlohr Bueso wrote:
> I got good numbers, recovering the performance drop I noticed with the
> i_mmap_mutex to rwsem patches.
That's good. I remembered that the earlier version of the patch not
only recovered the performance drop, but also provide some boost when
you switch from i_mmap_mutex to rwsem for aim7. Do you see similar
boost with this version?
> Looking forward to a more upstreamable
> patchset that deals with this work, including the previous patches.
>
> One thing that's bugging me about this series though is the huge amount
> of duplicated code being introduced to rwsems from mutexes. We can share
> common functionality such as mcs locking (perhaps in a new file under
> lib/), can_spin_on_owner() and owner_running(), perhaps moving those
> functions into sheduler code, were AFAIK they were originally.
I think that MCS locking is worth breaking out as its
own library. After we've done that, the rest of
the duplication are minimal. It is easier
to keep them separate as there are some rwsem
specific logic that may require tweaking
to can_spin_on_owner and owner_running.
Thanks.
Tim
--
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:[~2013-08-07 0:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 23:26 Tim Chen
2013-06-19 13:16 ` Ingo Molnar
2013-06-19 16:53 ` Tim Chen
2013-06-26 0:19 ` Tim Chen
2013-06-26 9:51 ` Ingo Molnar
2013-06-26 21:36 ` Tim Chen
2013-06-27 0:25 ` Tim Chen
2013-06-27 8:36 ` Ingo Molnar
2013-06-27 20:53 ` Tim Chen
2013-06-27 23:31 ` Tim Chen
2013-06-28 9:38 ` Ingo Molnar
2013-06-28 21:04 ` Tim Chen
2013-06-29 7:12 ` Ingo Molnar
2013-07-01 20:28 ` Tim Chen
2013-07-02 6:45 ` Ingo Molnar
2013-07-16 17:53 ` Tim Chen
2013-07-23 9:45 ` Ingo Molnar
2013-07-23 9:51 ` Peter Zijlstra
2013-07-23 9:53 ` Ingo Molnar
2013-07-30 0:13 ` Tim Chen
2013-07-30 19:24 ` Ingo Molnar
2013-08-05 22:08 ` Tim Chen
2013-07-30 19:59 ` Davidlohr Bueso
2013-07-30 20:34 ` Tim Chen
2013-07-30 21:45 ` Davidlohr Bueso
2013-08-06 23:55 ` Davidlohr Bueso
2013-08-07 0:56 ` Tim Chen [this message]
2013-08-12 18:52 ` Ingo Molnar
2013-08-12 20:10 ` Tim Chen
2013-06-28 9:20 ` Ingo Molnar
[not found] <1371165333.27102.568.camel@schen9-DESK>
[not found] ` <1371167015.1754.14.camel@buesod1.americas.hpqcorp.net>
2013-06-14 16:09 ` Tim Chen
2013-06-14 22:31 ` Davidlohr Bueso
2013-06-14 22:44 ` Tim Chen
2013-06-14 22:47 ` Michel Lespinasse
2013-06-17 22:27 ` Tim Chen
2013-06-16 9:50 ` Alex Shi
2013-06-17 16:22 ` Davidlohr Bueso
2013-06-17 18:45 ` Tim Chen
2013-06-17 19:05 ` Davidlohr Bueso
2013-06-17 22:28 ` Tim Chen
2013-06-17 23:18 ` Alex Shi
2013-06-17 23:20 ` Alex Shi
2013-06-17 23:35 ` Davidlohr Bueso
2013-06-18 0:08 ` Tim Chen
2013-06-19 23:11 ` Davidlohr Bueso
2013-06-19 23:24 ` Tim Chen
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=1375836988.22432.435.camel@schen9-DESK \
--to=tim.c.chen@linux.intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=andi@firstfloor.org \
--cc=dave.hansen@intel.com \
--cc=davidlohr.bueso@hp.com \
--cc=davidlohr@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.r.wilcox@intel.com \
--cc=mgorman@suse.de \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=walken@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox