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(a)cc.gatech.edu