linux-kernel - Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks / restartable sequences

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 13 Jul 2015 11:57:57 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Chris Mason <clm@...com>, Andy Lutomirski <luto@...capital.net>,
	"ksummit-discuss@...ts.linuxfoundation.org" 
	<ksummit-discuss@...ts.linuxfoundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Shaohua Li <shli@...com>
Subject: Re: [Ksummit-discuss] [CORE TOPIC] lightweight per-cpu locks /
 restartable sequences

On Fri, Jul 10, 2015 at 12:26:21PM -0500, Christoph Lameter wrote:
> On Thu, 9 Jul 2015, Chris Mason wrote:
> 
> > I think the topic is really interesting and we'll be able to get numbers
> > from production workloads to help justify and compare different
> > approaches.
> 
> Ok that would be important. I also think that the approach may be used
> in kernel to reduce the overhead of CONFIG_PREEMPT and also to implement
> fast versions of this_cpu_ops for non x86 architectures and maybe even

There is nothing stopping people from trying this in-kernel, in fact
that would be lots easier as we do not have to commit to any one
specific ABI for that.

Also, I don't think we need a schedule check for the in-kernel usage,
pure interrupt should be good enough, nobody should (want to) call
schedule() while inside such a critical section, which leaves us with
involuntary preemption, and those are purely interrupt driven.

Now the 'problem' is finding these special regions fast, the easy
solution is the same as the one proposed for userspace, one big section.
That way the interrupt only has to check if the IP is inside this
section which is minimal effort.

The down side is that all percpu ops would then end up being full
function calls. Which on some archs is indeed faster than disabling
interrupts, but not by much I'm afraid.

> optimize the x86 variants if interrupts also can detect critical sections
> and restart at defined points.

I really don't see how we can beat %GS prefixes with any such scheme.
--
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/