lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20071002064620.GA26638@elte.hu> Date: Tue, 2 Oct 2007 08:46:20 +0200 From: Ingo Molnar <mingo@...e.hu> To: David Schwartz <davids@...master.com> Cc: linux-kernel@...r.kernel.org Subject: Re: yield API * David Schwartz <davids@...master.com> 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 majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists