Re: preemp / nonpreemp

Re: preemp / nonpreemp

[pnilesh]

Hi,

On Tue, Apr 18, 2000 at 01:50:20PM +0530, pnilesh@in.ibm.com wrote:
>
>  Does it mean that I can go and write schedule () in the kernel and it
> should             not create any problems ?/* not in handler */

1 But will there be any complication as Eric told ?

It will be fine: it happens all over the place.  It's the standard
mechanism used to sleep on IO events.  Preemption implies that a timer
interrupt can forcibly reschedule a kernel task, and that won't ever
happen on current kernels.  Voluntary rescheduling, on the other hand,
is quite proper.

2 Is there any plan to make Linux kernel preemptable ?
3 What could be performance gain/loss compared to the current kernels ?

Nilesh


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: preemp / nonpreemp

[Stephen C. Tweedie]

Hi,

On Tue, Apr 18, 2000 at 04:19:00PM +0530, pnilesh@in.ibm.com wrote:
> >  Does it mean that I can go and write schedule () in the kernel and it
> > should             not create any problems ?/* not in handler */
> 
> 1 But will there be any complication as Eric told ?

No, none.

> It will be fine: it happens all over the place.  It's the standard
> mechanism used to sleep on IO events.  Preemption implies that a timer
> interrupt can forcibly reschedule a kernel task, and that won't ever
> happen on current kernels.  Voluntary rescheduling, on the other hand,
> is quite proper.
> 
> 2 Is there any plan to make Linux kernel preemptable ?

Some talk, no definite plans.

> 3 What could be performance gain/loss compared to the current kernels ?

It would probably be a performance loss overall.  However, it would
allow for better response time guarantees.  It's the sort of thing 
best done only when response time is absolutely the most important
issue: if you use the RTLinux real time kernel, for example, then you
can make certain tasks operate in a fully preemptible environment 
without changing the whole of the kernel.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: preemp / nonpreemp

[Eric W. Biederman]

pnilesh@in.ibm.com writes:

>   Using the architecture it is also possible
> to prempt kernel threads that don't hold the big kernel lock on
> non-SMP systems as well.
> 
>  Does it mean that I can go and write schedule () in the kernel and it
> should             not create any problems ?/* not in handler */

Right.  As a general rule you can never assume any function call
doesn't call schedule in the kernel.

> 
>   non-SMP premption probably won't appear until
> early 2.5 however as it may have a few complications.
> 
> Can you tell me any complication ?

The compilications were in partially balance pairs like:
spin_lock_irqsave....
spin_unlock...
restore_flags....

That the proposed trivial implentations of the locking
primitives might not handle quite correctly.

That's for premption in the kernel not calling schedule.
You can find the details on the lowlatency thread a while
ago on linux-kernel.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: preemp / nonpreemp

[pnilesh]

  Using the architecture it is also possible
to prempt kernel threads that don't hold the big kernel lock on
non-SMP systems as well.

 Does it mean that I can go and write schedule () in the kernel and it
should             not create any problems ?/* not in handler */

  non-SMP premption probably won't appear until
early 2.5 however as it may have a few complications.

Can you tell me any complication ?

Nilesh


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: preemp / nonpreemp

[Stephen C. Tweedie]

Hi,

On Tue, Apr 18, 2000 at 01:50:20PM +0530, pnilesh@in.ibm.com wrote:
> 
>  Does it mean that I can go and write schedule () in the kernel and it
> should             not create any problems ?/* not in handler */

It will be fine: it happens all over the place.  It's the standard
mechanism used to sleep on IO events.  Preemption implies that a timer
interrupt can forcibly reschedule a kernel task, and that won't ever
happen on current kernels.  Voluntary rescheduling, on the other hand,
is quite proper.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

preemp / nonpreemp

[pnilesh]

The Linux kernel is preemptable.

Does the preemption mean that inside system calls in kernel a call to
schedule is possible .
Or is there more to it .


Nilesh Patel


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: preemp / nonpreemp

[Eric W. Biederman]

pnilesh@in.ibm.com writes:

> The Linux kernel is preemptable.
> 
> Does the preemption mean that inside system calls in kernel a call to
> schedule is possible .
> Or is there more to it .

Well there is the obvious part about being able to prempt user space
from a timer tick which gives you most of the work.

As far as internally to the kernel on a SMP box unless you 
are holding the big kernel lock to threads can be running at the
same time in kernel.  Using the architecture it is also possible
to prempt kernel threads that don't hold the big kernel lock on
non-SMP systems as well.  non-SMP premption probably won't appear until
early 2.5 however as it may have a few complications.

Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: preemp / nonpreemp

[Stephen C. Tweedie]

Hi,

On Tue, Apr 18, 2000 at 09:42:27AM +0530, pnilesh@in.ibm.com wrote:
> The Linux kernel is preemptable.

Not by any normal definition.  The kernel is not preempted: any
scheduler interrupt which occurs while kernel code is running will
not cause a reschedule.

Kernel code _can_ be rescheduled, but only explicitly by calling
schedule(), or implicitly by calling some function which performs
a sleeping operation (including page faults).
> 
> Does the preemption mean that inside system calls in kernel a call to
> schedule is possible .

It is possible, yes, but it will not happen in a preemptive manner.

--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/