[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1375836988.22432.435.camel@schen9-DESK>
Date: Tue, 06 Aug 2013 17:56:28 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Davidlohr Bueso <davidlohr@...com>
Cc: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Andrea Arcangeli <aarcange@...hat.com>,
Mel Gorman <mgorman@...e.de>, "Shi, Alex" <alex.shi@...el.com>,
Andi Kleen <andi@...stfloor.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Michel Lespinasse <walken@...gle.com>,
Davidlohr Bueso <davidlohr.bueso@...com>,
"Wilcox, Matthew R" <matthew.r.wilcox@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
linux-mm <linux-mm@...ck.org>
Subject: Re: Performance regression from switching lock to rw-sem for
anon-vma tree
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists