linux-kernel - Re: yield

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: <20071003121646.GB3828@ff.dom.local>
Date:	Wed, 3 Oct 2007 14:16:46 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	David Schwartz <davids@...master.com>,
	linux-kernel@...r.kernel.org
Subject: Re: yield

On Wed, Oct 03, 2007 at 01:56:46PM +0200, Ingo Molnar wrote:
> 
> * Jarek Poplawski <jarkao2@...pl> wrote:
> 
> > On Wed, Oct 03, 2007 at 12:55:34PM +0200, Dmitry Adamushko wrote:
> > ...
> > > just a quick patch, not tested and I've not evaluated all possible
> > > implications yet.
> > > But someone might give it a try with his/(her -- are even more
> > > welcomed :-) favourite sched_yield() load.
> > 
> > Of course, after some evaluation by yourself and Ingo the most 
> > interesting should be Martin's Michlmayr testing, so I hope you'll Cc 
> > him too?!
> 
> My current take on this: queue the current task right to the next 
> position in the tree (this is what this patch achieves in essence) was 
> one of the yield implementations we already tried in CFS but it didnt 
> meet the expectations of some apps. So i can only repeat my argument: 
> this is not something that can be "solved" in the way you imagine and 
> your arguments just reiterate the path that CFS has already taken in the 
> past. So please do not expect _us_ to go out and pester people. If 
> people feel so inclined, they are of course welcome to test out various 
> approaches. (they might as well try the original yield-granularity patch 
> which also makes the amount of "delay" tunable, so the ideal amount of 
> delay can be figured out. And of course they should also try the 
> existing yield flag.)

I'm terribly sorry! Of course, the last thing I would like is to
pester anybody. I simply wasn't sure you've told about the same
idea. And of course, there is no reason to go back to something
checked before.

Thanks,
Jarek P.
-
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/