Re: [linux-audio-dev] Re: [Alsa-devel] RFC: Preemption on interrupt in Linux kernel

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: [Alsa-devel] RFC: Preemption on interrupt in Linux kernel
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Wed Dec 12 2001 - 18:21:53 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Dec 12 2001 - 18:20:19 EET