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: [EMAIL PROTECTED]