Messages in this thread | | | Date | Tue, 2 Oct 2007 08:26:26 +0200 | From | Ingo Molnar <> | Subject | Re: Network slowdown due to CFS |
| |
* David Schwartz <davids@webmaster.com> wrote:
> > at a quick glance this seems broken too - but if you show the > > specific code i might be able to point out the breakage in detail. > > (One underlying problem here appears to be fairness: a quick > > unlock/lock sequence may starve out other threads. yield wont solve > > that fundamental problem either, and it will introduce random > > latencies into apps using this memory allocator.) > > You are assuming that random latencies are necessarily bad. Random > latencies may be significantly better than predictable high latency.
i'm not really assuming anything, i gave a vague first impression of the vague example you gave (assuming that the yield was done to combat fairness problems). This is a case where the human language shows its boundaries: statements that are hard to refute with certainty because they are too vague. So i'd really suggest you show me some sample/real code - that would move this discussion to a much more productive level.
but i'll attempt to weave the chain of argument one step forward (in the hope of not distorting your point in any way): _if_ the sched_yield() call in that memory allocator is done because it uses a locking primitive that is unfair (hence the memory pool lock can be starved), then the "guaranteed large latency" is caused by "guaranteed unfairness". The solution is not to insert a random latency (via a sched_yield() call) that also has a side-effect of fairness to other tasks, because this random latency introduces guaranteed unfairness for this particular task. The correct solution IMO is to make the locking primitive more fair _without_ random delays, and there are a number of good techniques for that. (they mostly center around the use of futexes)
one thing that is often missed is that most of the cost of a yield() is in the system call and the context-switch - quite similar to the futex slowpath. So there's _no_ reason to not use a futexes on Linux. (yes, there might be historic/compatibility or ease-of-porting arguments but those do not really impact the fundamental argument of whether something is technically right or not.)
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |