![]() | |||||||||||||
Messages in this thread |
On Wed, Jul 05, 2006 at 10:49:38AM +1000, Peter Williams wrote: > Con Kolivas wrote: > >On Wednesday 05 July 2006 09:35, Peter Williams wrote: > >Could we just call it SCHED_IDLEPRIO since it's the same thing and there > >are tools out there that already use this name? That makes quite some sense, seconded. Plus, I like SCHED_IDLEPRIO more than SCHED_BGND, since it's more descriptive when stuff happens and when not (but of course the SCHED_BGND name is shorter). > I'm easy. Which user space visible headers contain the definition? > That's the only place that it matters. When I was writing a program to > use this feature, I couldn't find a header that defined any of the > scheduler policies that was visible in user space (of course, that > doesn't mean there isn't one - just that I couldn't find it). > > Peter > PS Any programs that use SCHED_IDLEPRIO should work as long as its value > is defined as 4. OK, nice, but: 2.6.17-ck1: /* * Scheduling policies */ #define SCHED_NORMAL 0 #define SCHED_FIFO 1 #define SCHED_RR 2 #define SCHED_BATCH 3 #define SCHED_ISO 4 #define SCHED_IDLEPRIO 5 #define SCHED_MIN 0 #define SCHED_MAX 5 Arggl. So what does that tell us? Does it tell us that the new policy should indeed be called SCHED_BGND so that user-space programs that make use of a policy (e.g. schedtool or any user-space app that wants to adjust its policy on its own) can figure out which policy number to use (the 4 vs. 5 difference) by #ifdef SCHED_IDLEPRIO elseif SCHED_BGND checks? A less favourable solution would be to rename SCHED_BGND to SCHED_IDLEPRIO but keep the current last policy number (4) for it, since that would introduce a gross conflict (or do programs always go after the policy name defines instead of the raw policy numbers?). Given this issue, maybe best would be to add SCHED_IDLEPRIO *and* SCHED_ISO to mainline at the same time, in order to keep the current policy numbering extension as done in -ck. Or maybe we should even introduce a more flexible way of dealing scheduling policy registration and listing? A numbered solution that changes on a whim whenever someone adds his own policy may be.... numbered ;) (in terms of days, that is). Semi-hard-coding scheduling numbers that get used by user-space sounds somewhat hackish to me, maybe we should instead (or additionally?) have a query API that returns a list of policy numbers for a given query input (near-hard realtime features, non-root access, interactivity, cache usage friendliness, batched operation, background processing). What do other systems (*BSD, Solaris, ...) do in this case? Andreas Mohr - 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/ | ||||||||||||
| Last update: 2006-07-05 08:09 [from the cache] ©2003-2008 | |||||||||||||