* David Schwartz <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
