[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy0nKSbr6YRUV62Ns9E53yJ9Wf1KHd2+mh+G12Co-tsiA@mail.gmail.com>
Date: Wed, 1 Jul 2015 14:54:59 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Daniel Wagner <wagi@...om.org>
Cc: Ingo Molnar <mingo@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Oleg Nesterov <oleg@...hat.com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...hat.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
der.herr@...r.at, Davidlohr Bueso <dave@...olabs.net>,
Rik van Riel <riel@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>,
Jeff Layton <jlayton@...chiereds.net>
Subject: Re: [RFC][PATCH 00/13] percpu rwsem -v2
On Tue, Jun 30, 2015 at 10:57 PM, Daniel Wagner <wagi@...om.org> wrote:
>
> And an attempt at visualization:
>
> http://monom.org/posix01/sweep-4.1.0-02756-ge3d06bd.png
> http://monom.org/posix01/sweep-4.1.0-02769-g6ce2591.png
Ugh. The old numbers look (mostly) fairly tight, and then the new ones
are all over the map, and usually much worse.
We've seen this behavior before when switching from a non-sleeping
lock to a sleeping one. The sleeping locks have absolutely horrible
behavior when they get contended, and spend tons of CPU time on the
sleep/wakeup management, based on almost random timing noise. And it
can get orders of magnitude worse if there are any nested locks that
basically trigger trains of that kind of behavior.
In general, sleeping locks are just horribly horribly bad for things
that do small simple operations. Which is what fs/locks.c does.
I'm not convinced it's fixable. Maybe the new rwsem just isn't a good idea.
Linus
--
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