linux-kernel - Re: [rfc] "fair" rw spinlocks

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: <alpine.LFD.2.00.0911300914240.2872@localhost.localdomain>
Date:	Mon, 30 Nov 2009 09:18:31 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nick Piggin <npiggin@...e.de>
cc:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [rfc] "fair" rw spinlocks



On Mon, 30 Nov 2009, Nick Piggin wrote:
> 
> Two questions. Firstly, does tasklist_lock benefit much from read
> side paralellism? Looking at some of the critical sections some seem
> to hold it for quite a while (over task and thread iterations). So
> it might not be the right thing to convert it to a spinlock?

I do agree that it's a potential problem.

> Secondly:
> 
> > 	static void tasklist_read_lock(void)
> > 	{
> > 		preempt_disable();
> > 		if (!current->tasklist_count++)
> 
> What happens if an interrupt and nested tasklist_read_lock() happens
> here?

You're right. We'd still need to disable hardware interrupts. Very 
annoying, because that is pretty much _guaranteed_ to eat up any advantage 
of the faster spin_unlock path. 

So scratch that approach. My earlier suggestion still looks technically 
correct, but has all the performance disadvantages.

The best option really would be to try to make it all use RCU, rather than 
paper over things. That _really_ should improve performance.

			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/