* David Schwartz <[email protected]> wrote:
> > These are generic statements, but i'm _really_ interested in the
> > specifics. Real, specific code that i can look at. The typical Linux
> > distro consists of in execess of 500 millions of lines of code, in
> > tens of thousands of apps, so there really must be some good, valid
> > and "right" use of sched_yield() somewhere in there, in some
> > mainstream app, right? (because, as you might have guessed it, in
> > the past decade of sched_yield() existence i _have_ seen my share of
> > sched_yield() utilizing user-space code, and at the moment i'm not
> > really impressed by those examples.)
>
> Maybe, maybe not. Even if so, it would be very difficult to find.
> Simply grepping for sched_yield is not going to help because
> determining whether a given use of sched_yield is smart is not going
> to be easy.
sched_yield() has been around for a decade (about three times longer
than futexes were around), so if it's useful, it sure should have grown
some 'crown jewel' app that uses it and shows off its advantages,
compared to other locking approaches, right?
For example, if you asked me whether pipes are the best thing for
certain apps, i could immediately show you tons of examples where they
are. Same for sockets. Or RT priorities. Or nice levels. Or futexes. Or
just about any other core kernel concept or API. Your notion that
showing a good example of an API would be "difficult" because it's hard
to determine "smart" use is not tenable i believe and does not
adequately refute my pretty plain-meaning "it does not exist" assertion.
If then this is one more supporting proof for the fundamental weakness
of the sched_yield() API. Rarely are we able to so universally condemn
an API: real-life is usually more varied and even for theoretically
poorly defined APIs _some_ sort of legitimate use does grow up.
APIs that are not in any real, meaningful use, despite a decade of
presence are not really interesting to me personally. (especially in
this case where we know exactly _why_ the API is used so rarely.) Sure
we'll continue to support it in the best possible way, with the usual
kernel maintainance policy: without hurting other, more commonly used
APIs. That was the principle we followed in previous schedulers too. And
if anyone has a patch to make sched_yield() better than it is today, i'm
of course interested in it.
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]
