linux-kernel - Re: yield API

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]

Date:	Wed, 12 Dec 2007 23:43:51 -0500
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Jesper Juhl <jesper.juhl@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, David Schwartz <davids@...master.com>,
	linux-kernel@...r.kernel.org
Subject: Re: yield API

On Dec 12, 2007, at 17:39:15, Jesper Juhl wrote:
> On 02/10/2007, Ingo Molnar <mingo@...e.hu> wrote:
>> sched_yield() has been around for a decade (about three times  
>> longer than futexes were around), so if it's useful, it sure  
>> should have grown some 'crown jewel' app that uses it and shows  
>> off its advantages, compared to other locking approaches, right?
>
> I have one example of sched_yield() use in a real app.  
> Unfortunately it's proprietary so I can't show you the source, but  
> I can tell you how it's used.
>
> The case is this:  Process A forks process B. Process B does some  
> work that takes aproximately between 50 and 1000ms to complete  
> (varies), then it creates a file and continues to do other work.   
> Process A needs to wait for the file B creates before it can  
> continue. Process A *could* immediately go into some kind of "check  
> for file; sleep n ms" loop, but instead it starts off by calling  
> sched_yield() to give process B a chance to run and hopefully get  
> to the point where it has created the file before process A is  
> again scheduled and starts to look for it - after the single sched  
> yield call, process A does indeed go into a "check for file; sleep  
> 250ms;" loop, but most of the time the initial sched_yield() call  
> actually results in the file being present without having to loop  
> like that.

That is a *terrible* disgusting way to use yield.  Better options:
   (1) inotify/dnotify
   (2) create a "foo.lock" file and put the mutex in that
   (3) just start with the check-file-and-sleep loop.

> Now is this the best way to handle this situation? No.  Does it  
> work better than just doing the wait loop from the start? Yes.

It works better than doing the wait-loop from the start?  What  
evidence do you provide to support this assertion?  Specifically, in  
the first case you tell the kernel "I'm waiting for something but I  
don't know what it is or how long it will take"; while in the second  
case you tell the kernel "I'm waiting for something that will take  
exactly X milliseconds, even though I don't know what it is.  If you  
really want something similar to the old behavior then just replace  
the "sched_yield()" call with a proper sleep for the estimated time  
it will take the program to create the file.

> Is this a good way to use sched_yield()? Maybe, maybe not.  But it  
> *is* an actual use of the API in a real app.

We weren't looking for "actual uses", especially not in binary-only  
apps.  What we are looking for is optimal uses of sched_yield(); ones  
where that is the best alternative.  This... certainly isn't.

Cheers,
Kyle Moffett

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