On Thu, Apr 12, 2007 at 03:31:31PM +0200, Andi Kleen wrote: > The only way I could think of to make sched_yield work the way they > expect would be to define some way of gang scheduling and give > sched_yield semantics that it preferably yields to other members > of the gang. > But it would be still hard to get these semantics (how to define > the gangs) into your uncontrollable broken applications and also > it has the risk of either unfairness or not full utilization of the > machine. Getting it to scale well on MP systems would be also likely > a challenge.
Gang scheduling isn't a squishy concept whose name can be arbitrarily repurposed. Perhaps "group scheduling" or similar would be appropriate if the standard gang scheduling semantics are not what you have in mind. Standard gang scheduling would not be appropriate for applications that don't know what they're doing. All threads of a gang falling asleep when one sleeps (or more properly, the gang is considered either runnable or unrunnable as a unit) is not to be taken lightly. I'd call this something like a "directed yield with a group as a target," but I wouldn't actually try to do this. I'd try to provide ways for a directed yield to donate remaining timeslice and dynamic priority if possible to a particular task associated with a resource, for instance, a futex or SysV semaphore owner. The priority inversion one desperately wants to avoid is the resource owner running out of timeslice or otherwise losing priority to where it falls behind busywaiters such as callers of sched_yield for the purposes of multitier locking. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/