On Jan 4, 9:41 am, "Amine" <ami...@xxxxxxxxx> wrote:
Am i corect to say that the mutex does schedule the threads to be executed
in something like a FIFO manner ( and this is good for realtime
applications).
Some may, but IMO the ideal implementation would not. LIFO tends to be
far more efficient. Whichever thread most recently blocked is most
likely to have its data warmest in the cache. The one that has been
blocking the longest likely would run the slowest.
The scheduler should schedule the thread that can run the best.
Fairness is *not* a POSIX requirement, and IMO, performance should
almost always win out over fairness. (See my other post on why
'technical' notions of fairness to threads may not make applications
any fairer and definitely hurt performance.)
To take this a step further...
Fairness always depends on the situation -- there's no possible way to
objectively and universally define "fair". But one CAN objectively
define (and implement) "fastest" (well, OK, "fast") in specific
scheduling situations.
One can BUILD one's own synchronization layer on top of these primitives
that schedules application threads in a way that meets the module's
needs (whether you call that "fair", "throughput", "fast", or whatever),
and that layer will always work best when the primitives were designed
to be FAST rather than for some entirely different definition of "fair".
.
Re: IO scheduler based IO controller V10 ... I would like to know a bit more specific about Namuman's scheduler design.... So providing fairness for NOOP is not an issue. ... Max bandwidth Controller or Proportional bandwidth controller ... Or we want max bandwidth control where a group is not allowed to use the ... (Linux-Kernel)
Comments on the KSE option ... John, I appreciate that you have made KSE an option, but the way you have done it shows a complete misundertanding of what is there. ... A naive scheduler would give you 1000 cpu slots and me 1. ... The fairness algorythm that you have made 'optional' is a very crude one and I had thought that by now someone would have written a better one, ... work only to discover at the end that it is the only thread on the ksegrp, and therefore always eligible to run). ... (freebsd-current)
Re: [RFC] scheduler: improve SMP fairness in CFS ... If I have 3 threads and 2 processors, and I have a choice between fairly giving each thread 1.0 billion cycles during the next second, or unfairly giving two of them 1.1 billion cycles and giving the other 0.9 billion cycles, then we can have a useful discussion about where we want to draw the line on the fairness/performance tradeoff. ... I think we should be more precise on what fairness means. ... The definition is that a scheduler is proportionally fair if for any task in any time interval, the task's lag is bounded by a constant. ... The scheduler keeps a set data structures, called Trio groups, to maintain the weight or reservation of each thread group and the local weight of each member thread. ... (Linux-Kernel)
Re: [RFC] scheduler: improve SMP fairness in CFS ... If I have 3 threads and 2 processors, and I have a choice between fairly giving each thread 1.0 billion cycles during the next second, or unfairly giving two of them 1.1 billion cycles and giving the other 0.9 billion cycles, then we can have a useful discussion about where we want to draw the line on the fairness/performance tradeoff. ... I've said from the beginning that I think that anyone who desperately needs perfect fairness should be explicitly enforcing it with the aid of realtime priorities. ... I do not, however, believe that we should take it to the extreme of wasting CPU cycles on migrations that will not improve performance for *any* task, just to avoid letting some tasks get ahead of others. ... If we're going to implement a user interface beyond simply interpreting existing priorities more precisely, it would be nice if this was part of a framework with a broader vision, such as a scheduler economy.... (Linux-Kernel)
Re: Comments on the KSE option ... A naive scheduler would give you 1000 cpu slots and me 1. ... The fairness algorythm that you have made 'optional' is a very crude one and I had thought that by now someone would have written a better one, ... If it is made a project goal that threads should be unfair,... work only to discover at the end that it is the only thread on the ksegrp, and therefore always eligible to run). ... (freebsd-current)
