On Mon, Oct 01, 2007 at 06:25:07PM +0200, Ingo Molnar wrote:Very clever move! And I see some people have catched this... Since sched_yeld() is a very general purpose tool, it can be easily replaced by others, of course, just like probably half of all system calls. And such things are done often in a code during optimization. But, IMHO, the main value of sched_yield() is it's easy to use and very readable way to mark some place. Sometimes even test if such idea is reasonable at all... Otherwise, many such possibilities could easily stay forgotten forever. But you are right, the value of this call shouldn't be exaggerated, and my proposal was an overkill. Anyway, it seems, there could be imagined something better than current ways of doing this. They look like two extremes and something in between and not too complicated should suffice. Currently, I wonder if simply charging (with a key recalculated) such a task for all the time it could've used isn't one of such methods. It seems, it's functionally analogous with going to the end of que of tasks with the same priority according to the old sched. Regards, Jarek P. -
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Hiten Pandya | Re: up? (emacs docbook xml ide) |
| Martin Michlmayr | Network slowdown due to CFS |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Natalie Protasevich | [BUG] New Kernel Bugs |
| Yaroslav Tarasenko | Re: PC-BSD |
| Ben Cadieux | DragonFly MBR |
| justin | Re: dragonfly pdf documentation |
| dark0s Optik | DragonFly over Sony Vaio |
