On Wednesdayen den 12 December 2001 11.19, you wrote: > At Tue, 11 Dec 2001 17:34:34 -0500, > > Paul Davis wrote: > > >I'm thinking for the benefits that low latency audio applications will > > >have from preemption of running task in favour of the waiting task just > > >at end of interrupt handler execution (instead of end of time slice). > > > > > >I don't believe that such a mechanism is already in place in linux > > >kernel but I may be wrong. > > > > i think that there is such code in the LL patches. the return to user > > space codepath does a conditional_schedule() there. i think. if not, > > it was a feature of ingo's original LL patch series. > > As far as looking at the code, Andrew's patch doesn't include this > feature. It was only in Ingo's. > > > Takashi
Hmm... This should already be working for the cases when the running task is running in user space. See code in file linux/arch/i386/kernel/entry.S ret_from_intr jumps to ret_from_sys_call if the current process executes in user space. In ret_from_sys_call the need_resched flag is checked... The need_resched flag is set if a process with higher priority (goodness) is woken up last line in function reshedule_idle linux/kernel/schedule.c. [called from try_to_wake_up, called from wake_up, called when a process was waiting for something that is now ready] BUT this does not work if the running process was running in the kernel. But note that the need_resched flag is checked when leaving. This is where the patches are comes in: * Ingo Molnars - inserting checks for need_resched wherever it was needed in the kernel. * Andrew Morton - inserting in the most frequently used places only. But note the - Don't do this list * Montavista/Robert Love - allow reschedules in kernel, by using the SMP locks as a preemtion not allowed indicator. Additional context switch locks needed where per CPU data was used. And some checks for need_resched are probably needed in some long held places - like VM handling, walking the list of all memory... Another thing: note that you have no guarantees when not running as RT process. And finally: there is NO need to use the HIGHEST SCHED_FIFO priority only because the latencytest program does. Aim for middle. Increase it slightly if your execution time is really short. Decrease if long. Why? Because your process is most likely the only RT process in the system and will be selected before any non RT process. But if there is another RT process, you need to cooperate somewhat. -- Roger Larsson Skellefte� Sweden
