Deadline scheduling for Linux [LWN.net]

Deadline scheduling for Linux

Posted Oct 13, 2009 17:11 UTC (Tue) by nix (subscriber, #2304)
Parent article: Deadline scheduling for Linux

sched_setscheduler_ex()? What is it with people and really bad syscall names lately? If this really is specific to deadline parameters, sched_setscheduler_deadline() would surely be a better name.

to post comments

Deadline scheduling for Linux

Posted Oct 13, 2009 22:37 UTC (Tue) by vieuxtech@gmail.com (guest, #54592) [Link] (2 responses)

It's not clear why there needs to be a new syscall. sched_setscheduler() already exists, and it's struct sched_param argument can be extended to include parameters specific to particular scheduler policies.

Deadline scheduling for Linux

Posted Oct 14, 2009 10:26 UTC (Wed) by raistlin (guest, #37586) [Link] (1 responses)

Well, extending struct sched_param is more than possible, I agree, but it would be a _really_big_ ABI issue, don't you think?
Especially when a 'legacy' binary comes to, e.g., a sched_getparam, and the data it gets will be bigger than expected... :-(

Regards,
Dario

Deadline scheduling for Linux

Posted Oct 14, 2009 21:10 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

but it would be a _really_big_ ABI issue, don't you think?

I was about to write about how that's not the case, but you're right: whose bright idea was it to have sched_getscheduler not take a length parameter like getpeername does?

Deadline scheduling for Linux

Posted Oct 14, 2009 10:34 UTC (Wed) by raistlin (guest, #37586) [Link] (5 responses)

:-D

Actually, good point!

In our intents _ex stands for EXtended, which means it can be used not only for this particular new scheduling policy, but for all the ones (if/when they will come! :-P) that needs the EXtended sched_param structure.

(It is the same name used by Xenomai for the same purpose, i.e., supporting new scheduling policies with extended parameters, such as POSIX's SCHED_SPORADIC.)

I think it _is_ a good thing to keep this general but, hey, we can discusss about that! :-)

Regards,
Dario

Deadline scheduling for Linux

Posted Oct 14, 2009 16:32 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

OK (though the name is reminiscent of the horrible Win32 API to my ears), but adding a new scheduler requiring different parameters would be another ABI change, wouldn't it, requiring another new syscall: the parameter type would change. Either that or you make the parameter type a void *, which is just ioctl() in new clothes and Linus would tear your lungs out.

Or something like that.

Deadline scheduling for Linux

Posted Oct 14, 2009 22:15 UTC (Wed) by raistlin (guest, #37586) [Link]

Well, this may be true or not, depending on the new new scheduler!

Generally speacking, you are definitely right, since each new scheduler/scheduling class could ask some room for its own parameter(s).
What we were thinking here is (and this also comes from some comments/suggestions we got on LKML):
- if we define a general enough task model, it is likely that even new
algorithms can deal with that, without the need of their very specific
fields;
- if we want, sched_param_ex could be bloated a little bit with some
padding or non-utilized field, reserved for future extensions.

However, I'm sure that, if things keep going, this issue will came up in LKML at some point, and then we we'll see what people there think... :-D

Thanks for your comments,
Dario

Deadline scheduling for Linux

Posted Oct 14, 2009 21:13 UTC (Wed) by quotemstr (subscriber, #45331) [Link] (1 responses)

When you created the _ex functions, why didn't you make them take length parameters like the socket-address ones do, thus solving the ABI compatibility problem once and for all?

Deadline scheduling for Linux

Posted Oct 15, 2009 5:29 UTC (Thu) by raistlin (guest, #37586) [Link]

Very, very nice idea!

/me more than considering that! :-D

Thanks,
Dario

Deadline scheduling for Linux

Posted Oct 22, 2009 10:05 UTC (Thu) by cesarb (subscriber, #6266) [Link]

This ..._ex() naming is really horrible. What do you do when you need to extend it again? Call it ..._ex2()? ..._ex_ex()?

Unix solved that naming problem in a much more elegant way a long time ago, by simply appending the number of parameters. So we have wait3() and wait4(); dup(), dup2(), and the new dup3(); pipe() and pipe2(); inotify_init() and inotify_init1(); and so on (see http://udrepper.livejournal.com/20407.html for how recent some of these are).