linux-kernel - Re: Re-tune x86 uaccess code for PREEMPT

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: <5206659F.9070705@zytor.com>
Date:	Sat, 10 Aug 2013 09:09:03 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Mike Galbraith <bitbucket@...ine.de>
CC:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	x86@...nel.org, mingo@...nel.org, torvalds@...ux-foundation.org
Subject: Re: Re-tune x86 uaccess code for PREEMPT_VOLUNTARY

On 08/09/2013 10:55 PM, Mike Galbraith wrote:
>>
>> Now, here is a bigger question: shouldn't we be deprecating/getting rid
>> of PREEMPT_VOUNTARY in favor of PREEMPT?
> 
> I sure hope not, PREEMPT munches throughput.  If you need PREEMPT, seems
> to me what you _really_ need is PREEMPT_RT (the real deal), so
> eventually depreciating PREEMPT makes more sense to me.
> 

Do you have any quantification of "munches throughput?"  It seems odd
that it would be worse than polling for preempt all over the kernel, but
perhaps the additional locking is what costs.

	-hpa


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