Subject: Re: [linux-audio-dev] new realtime scheduling policy
From: rm (async_AT_cc.gatech.edu)
Date: Tue Mar 18 2003 - 20:09:24 EET
On Tue, Mar 18, 2003 at 06:07:24PM +0100, Roger Larsson wrote:
> On Tuesday 18 March 2003 08:45, rm wrote:
> > hi all,
>
> With 2.4 kernels there are very few jiffies to share, 2.5 kernels have more.
> But jiffies are not a good unit...
that would depend on the period you set, but point taken.
> The second problem is that this patch adds code to hot areas in the kernel -
> it will slow down context switching for all processes.
> This can be made slightly better if you add unlikely/likely from
> linux/compiler.h
the only change i see in a hot path is in the goodness function and
only for ~SCHED_OTHER, so it shouldn't affect all processes. i don't
know that the addition to the timer interrupt is significant, since it
happens with a fixed frequency (but this is arguable).
> this wont work when jiffies wrap... I think there are functions/macros
> that can check this - time_after_eq?
> linux/include/linux/timer.h
right, as noted in the original message (i think).
> jiffies frequency depends on architecture and compilation options.
> At least you should scale with HZ in some way for wall clock parameters.
> (micro/nano seconds?)
agreed, it should probably be (u/n)seconds and then divide by HZ (i
think this is what the mach kernel does). however, the thing i like
about using ticks is that it avoids the possibility a programmer will
give values in seconds (or us or ns) which are actually equal when
turned into ticks.
> This will not be liked - growing task_struct with 4*5=20 bytes for every
> task... (This is probably the most important issue)
agreed.
> Could this data be made CPU local?
most likely. actually i had a similar thought this morning. instead of
per process, we can have a sysctl that gives the amount of time
reserved amongst all processors for non-realtime tasks. that will
avoid messing with the task_struct and allow people to use sched_fifo
programs unchanged. (it also means we don't have to do testing for
admittance when making reservations to prevent multiple rt tasks from
hogging the processor).
> Anyway, I think this patch has its place on linux-kernel. It will
> most likely be rejected but it shows that people are interested in
> these issues... (Who knows Ingo might get another bright idea... :-)
yup. just trying to work out the silly stuff first.
thanks,
rob
----
Robert Melby
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4255a
Internet: async_AT_cc.gatech.edu
This archive was generated by hypermail 2b28 : Tue Mar 18 2003 - 20:11:13 EET