| 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
| ||
|
Message-ID: <1302103507.2225.1391.camel@twins> Date: Wed, 06 Apr 2011 17:25:07 +0200 From: Peter Zijlstra <a.p.zijlstra@...llo.nl> To: Rik van Riel <riel@...hat.com> Cc: Alex Shi <alex.shi@...el.com>, linux-kernel@...r.kernel.org, mingo@...e.hu, tim.c.chen@...el.com, shaohua.li@...el.com Subject: Re: [PATCH] sched: recover sched_yield task running time increase On Wed, 2011-04-06 at 10:42 -0400, Rik van Riel wrote: > It appears they might not have figured out how to fix > their stuff :) As far as I can tell they're totally not interested in fixing their crap, it comes up every time we touch sched_yield() but nobody ever steps up and fixes things. > Would you have any hints on what the Java folks should > replace their calls to sched_yield with? > > Proper use of futexes from inside the JVM perhaps? Yeah, Darren was working on making adaptive spinning futexes, but still even without that, syscalls on x86 are so cheap there's really hardly any point in actually spinning in userspace. > Or should we export yield_to to userspace and have > them use that? :) *runs* Hehe, no, yield_to() is an absolute abomination (much like yield itself but worse), they have proper locks and should thus use proper primitives. -- 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/
Powered by blists - more mailing lists