In article <[EMAIL PROTECTED]> you wrote: > a) it may do so for a short and bound time, typically less than the > maximum acceptable latency for other tasks
if you have n threads in runq and each of them can have m<d (d=max latency deadline) overhead, you will have to account on d/n slices. This is typically not possible for larger number of ready threads. Therefore another aproach would be to make sure the next thread gets a smaller slice, but then you will have to move around that debit and distribute it fair, which is the whole problem we face here. (Besides it is not clear to me if fair scheduling gets the best results, see the X problem or compare threads vs. process vs. subsystems). Gruss Bernd PS: sorry for that Cc trimming, I need to get rid of my mail2news gateway, however I will make sure to copy important info to all concerend parties - dont think thats needed for my ramblings .) - 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/