Re: Detecting scheduler interference?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thread priority doesn't affect its timeslice length. It only affects whether
it will get the time slice. At any given moment, a thread ready to run with
the highest priority will get the processor. If there are several threads
with highest priority, they will be scheduled round-robin.

"JJ" <jcunews@xxxxxxxxxxxxx> wrote in message
news:Oc3D9GMmJHA.1252@xxxxxxxxxxxxxxxxxxxxxxx
drtodd13@xxxxxxxxxxx wrote:
time it is 10 microseconds but sometimes 10-20 milliseconds. If I run
the program with real-time priority then the number of spikes
decreases by roughly half. What I would like to do is prove the
hypothesis that the scheduler doing this. Is there some way to use
the thread information block (or anything else) to detect if this
thread has been unscheduled/rescheduled while running this function?

Even though a realtime process with a realtime thread (with priority
boost) has longer time slice than the system threads, IMO, other threads
are still running. It's just that they have much shorter time slice.

Other interferences are hardware interrupts (IRQ) (e.g. clock, keyboard)
which have the topmost priority and will interrupt anything and execute
the assigned IRQ handler - a system code. Although the system code might
have lower priority than the realtime process+thread, the hardware
interrupt has already take place. IRQs can be disabled (in kernel mode),
but not all of them. There is at least one that can not be disabled.

One way to detect interference is by looking at the thread's number of
context switches. Each context switch can mean either pausing or resuming
a thread (out or in to the scheduled thread).

More on this can be found in MSDN page entitled "Scheduling Priorities"
and "Context Switches".


.

Relevant Pages

  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: [RFC] cfq: adapt slice to number of processes doing I/O
    ... In the patch, if there are more than 3 processes performing concurrent ... I/O, we scale the time slice down proportionally. ... version of the ideal number of bytes the given priority should have ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... But anyway, based on the evidence, I think the problem is caused by the fact that the eatm tasks are running to completion in less than one time slice without sleeping and this means that they never have their priorities reassessed. ... The reason that it does this is that it gives newly forked processes a fairly high priority and if they're left to run for a full 120 msecs at that high priority they can hose the system. ... Having a shorter first time slice gives the scheduler a chance to reassess the task's priority before it does much damage. ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... this lockup somewhat and starts exhibiting this problem as a choking ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ...
    (Linux-Kernel)
  • Re: Multicores
    ... > Skybuck Flying wrote: ... time slice intervals have only a little to do with system ... Give an application a higher priority and it's threads will get a ... The threads of the high priority application will get longer time slices. ...
    (comp.arch)