linux-kernel - Re: [PATCH 5/7] percpu-rwsem: change it to rely on rss

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: <20150715185914.GB2101@redhat.com>
Date:	Wed, 15 Jul 2015 20:59:14 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Daniel Wagner <daniel.wagner@...-carit.de>,
	Davidlohr Bueso <dave@...olabs.net>,
	Ingo Molnar <mingo@...hat.com>, Tejun Heo <tj@...nel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] percpu-rwsem: change it to rely on rss_sync
	infrastructure

On 07/15, Paul E. McKenney wrote:
>
> On Sun, Jul 12, 2015 at 01:36:01AM +0200, Oleg Nesterov wrote:
> > Currently down_write/up_write calls synchronize_sched_expedited()
> > twice which is evil. Change this code to rely on rcu-sync primitives.
> > This avoids the _expedited "big hammer", and this can be faster in
> > the contended case or even in the case when a single thread does
> > down_write/up_write in a loop.
>
> But "evil" is such a strong word!  ;-)

I tried to be convincive ;)

But yes, to me this synchronize_sched_expedited() looks really annoying
because it is not friendly to other workloads.

> More seriously, introducing a read-side smp_mb()

Sure, we can penalize the readers and simplify this code. But the
main purpose of this primitive was "make the readers fast".

I'll write another email about this...

> My main concern would be the introduction of an exclusive lock for the
> writer, but if you are hitting the write-side acquisition that hard,
> perhaps you are having other bigger problems.

Sorry, I don't really understand... could you explain?

> Another concern would be performance in a workload where there are way
> more readers than writers, but enough writers so that there is not much
> more than one grace period's worth of spacing between them.  In that case,
> the readers are having to hit the global lock more frequently with this
> change than in the original.

Of course, this is true.

Oleg.

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