linux-kernel - Re: Performance regression from switching lock to rw-sem for anon-vma tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130628092039.GA29205@gmail.com>
Date:	Fri, 28 Jun 2013 11:20:39 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Tim Chen <tim.c.chen@...ux.intel.com>
Cc:	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>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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


* Tim Chen <tim.c.chen@...ux.intel.com> wrote:

> > Yet the 17.6% sleep percentage is still much higher than the 1% in the 
> > mutex case. Why doesn't spinning work - do we time out of spinning 
> > differently?
> 
> I have some stats for the 18.6% cases (including 1% more than 1 sleep 
> cases) that go to sleep and failed optimistic spinning. There are 3 
> abort points in the rwsem_optimistic_spin code:
> 
> 1. 11.8% is due to abort point #1, where we don't find an owner and 
> assumed that probably a reader owned lock as we've just tried to acquire 
> lock previously for lock stealing.  I think I will need to actually 
> check the sem->count to make sure we have reader owned lock before 
> aborting spin.

That looks like to be the biggest remaining effect.

> 2. 6.8% is due to abort point #2, where the mutex owner switches
> to another writer or we need rescheduling.
> 
> 3. Minuscule amount due to abort point #3, where we don't have
> a owner of the lock but need rescheduling

The percentages here might go down if #1 is fixed. Excessive scheduling 
creates wakeups and has a higher rate of preemption as well as waiting 
writers are woken.

There's a chance that if you fix #1 you'll get to the mutex equivalency 
Holy Grail! :-)

> See the other thread for complete patch of rwsem optimistic spin code: 
> https://lkml.org/lkml/2013/6/26/692
> 
> Any suggestions on tweaking this is appreciated.

I think you are on the right track: the goal is to eliminate these sleeps, 
the mutex case proves that it's possible to just spin and not sleep much.

It would be even more complex to match it if the mutex workload showed 
significant internal complexity - but it does not, it still just behaves 
like spinlocks, right?

Thanks,

	Ingo
--
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/