[Date Prev][Date Next] [Chronological] [Thread] [Top]

[rtl] plain linux periodic tasks



 
Tomasz asked about this and I thought others on the list would like to see it 
too. forgive me for sending a graphic to a mailing list. but it's very 
informative (I hope it doesn't get removed from this message).

here's an interesting 2-minute plot showing a machine churning its hard
drive, doing network access, and running intensive X jobs while running
a set_itimer() periodic job (in plain old linux 2.0.35 user space).  the job is 
a signal handler (software interrupt). we were using set_scheduler() priority 1,
FIFO scheduling. We've also tried priority 98, but it doesn't do any better.
We need to lock the memory, but haven't yet. if the HZ variable 
is changed, we can increase the periodic rate.

the plot shows that timeslicing isn't actually hurting us, except that 
itimer() apparently tries to schedule the task on even 10ms timeslices. we're
always w/in 30% of our goal: 2 time slices. the unit on the vertical axis is
microseconds elapsed between invocations of the periodic task - pretty reliably 
20, but not when other demanding tasks run (+/- 6ms).

we know the prioritising (sched_setscheduler)is working because the only way you 
can ^C a malfunctioning periodic proc is if the bash shell has equal or higher 
priority.

-Steve

GIF image