Preemptive linux - Linux

This is a discussion on Preemptive linux - Linux ; Hello, I've been reading a book about operating systems (operating systems concepts, seventh edition) and the author says "A preemptive kernel allows a process to be preempted while it is running in kernel mode. (...) Prior to Linux 2.6, the ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Preemptive linux

  1. Preemptive linux

    Hello,

    I've been reading a book about operating systems (operating systems
    concepts, seventh edition) and the author says "A preemptive kernel
    allows a process to be preempted while it is running in kernel mode.
    (...) Prior to Linux 2.6, the Linux kernel was nonpreemptive as well.
    However, with the release of the 2.6 kernel, Linux changed to the
    preemptive model."

    I've written a system call like this:

    int sys_foo(void)
    {
    while (1);
    return 0;
    }

    When I called it, however, the system hang and I was not able to do
    anything besides restarting it. Wouldn't that mean that the kernel is
    actually nonpreemptive, as if it were preemptive I would be able to get
    back to the shell and kill the process?

    I've called my syscall using that _syscall0 macro on sys/syscall.h. I
    would post the whole thing here but I don't have access to the code
    right now, but I think what I've said is enough to everyone to
    understand what I've done.

    I used linux 2.6.17-gentoo-r7 for the experiment.

    PS: Thank you to everyone who answered my post asking for suggestions
    for changing stuff in the kernel.

    []'s
    Rafael

  2. Re: Preemptive linux


    Rafael Almeida wrote:

    > Hello,
    >
    > I've been reading a book about operating systems (operating systems
    > concepts, seventh edition) and the author says "A preemptive kernel
    > allows a process to be preempted while it is running in kernel mode.
    > (...) Prior to Linux 2.6, the Linux kernel was nonpreemptive as well.
    > However, with the release of the 2.6 kernel, Linux changed to the
    > preemptive model."
    >
    > I've written a system call like this:
    >
    > int sys_foo(void)
    > {
    > while (1);
    > return 0;
    > }
    >
    > When I called it, however, the system hang and I was not able to do
    > anything besides restarting it. Wouldn't that mean that the kernel is
    > actually nonpreemptive, as if it were preemptive I would be able to get
    > back to the shell and kill the process?
    >
    > I've called my syscall using that _syscall0 macro on sys/syscall.h. I
    > would post the whole thing here but I don't have access to the code
    > right now, but I think what I've said is enough to everyone to
    > understand what I've done.
    >
    > I used linux 2.6.17-gentoo-r7 for the experiment.
    >

    Is your kernel premptible. have you enabled premption while menuconfig.


    > PS: Thank you to everyone who answered my post asking for suggestions
    > for changing stuff in the kernel.
    >
    > []'s
    > Rafael



  3. Re: Preemptive linux

    AFAIK, you need call preempt_check_resched() for make your syscall
    preemtible for opportunity to switch context. So your code should be
    like following:

    int sys_foo(void)
    {
    while (1)
    preempt_check_resched();
    return 0;
    }

    Also you need to set TIF_NEED_RESCHED flag for this thread if it should
    be rescheduled and when this thread call preempt_check_resched() in
    next time it will be rescheduled.

    Of course, preemption also must be enabled by preempt_enable().


  4. Re: Preemptive linux


    Alexander Krizhanovsky wrote:
    > AFAIK, you need call preempt_check_resched() for make your syscall
    > preemtible for opportunity to switch context. So your code should be
    > like following:
    >
    > int sys_foo(void)
    > {
    > while (1)
    > preempt_check_resched();
    > return 0;
    > }
    >
    > Also you need to set TIF_NEED_RESCHED flag for this thread if it should
    > be rescheduled and when this thread call preempt_check_resched() in
    > next time it will be rescheduled.
    >
    > Of course, preemption also must be enabled by preempt_enable().


    As I understand it, so long as you properly select preemption when you
    build the kernel, it should be enabled by default and no special calls
    should be needed. You only need to call 'preempt_check_resched' if
    preemption might be disabled and you still want to be able to be
    preempted at a particular point.

    I am not 100% sure, but this is my understanding of the code and the
    documentation.

    DS


  5. Re: Preemptive linux


    David Schwartz wrote:
    > You only need to call 'preempt_check_resched' if
    > preemption might be disabled and you still want to be able to be
    > preempted at a particular point.


    Did you mean thread can be preempted by timer interrupt (because of I
    don't know any other way by which thread with infinite loop can be
    preempted on UP machine)?

    AFAIK, just for SMP systems thread can be marked by TIF_NEED_RESCHED
    from timer_interrupt() but also not a really preempted...


  6. Re: Preemptive linux

    Alexander Krizhanovsky wrote:
    > David Schwartz wrote:
    >
    >>You only need to call 'preempt_check_resched' if
    >>preemption might be disabled and you still want to be able to be
    >>preempted at a particular point.

    >
    >
    > Did you mean thread can be preempted by timer interrupt (because of I
    > don't know any other way by which thread with infinite loop can be
    > preempted on UP machine)?


    Any interrupt, not just timer. Keyboard, serial port, network packet, etc.

    Basically, any point at which the kernel is not holding a spinlock (and
    a few other special cases) is a legal point to get preempted.

    Chris

  7. Re: Preemptive linux

    Rafael Almeida wrote:

    > I've written a system call like this:
    >
    > int sys_foo(void)
    > {
    > while (1);
    > return 0;
    > }
    >
    > When I called it, however, the system hang and I was not able to do
    > anything besides restarting it.


    Did you enable CONFIG_PREEMPT and recompile the kernel? It may not have
    been enbled by default.

    > Wouldn't that mean that the kernel is
    > actually nonpreemptive, as if it were preemptive I would be able to get
    > back to the shell and kill the process?


    With the code as shown, there's no way for you to kill the task once you
    go into that loop. You need an exit condition.

    That said, with CONFIG_PREEMPT I *think* you should still be able to do
    other stuff on the system--it would just always be running at 100% cpu.

    Chris

  8. Re: Preemptive linux

    Will this challenge the driver developer, such as reentrant function
    handling.

    Any comments?

    ABAI
    David Schwartz wrote:
    > Alexander Krizhanovsky wrote:
    > > AFAIK, you need call preempt_check_resched() for make your syscall
    > > preemtible for opportunity to switch context. So your code should be
    > > like following:
    > >
    > > int sys_foo(void)
    > > {
    > > while (1)
    > > preempt_check_resched();
    > > return 0;
    > > }
    > >
    > > Also you need to set TIF_NEED_RESCHED flag for this thread if it should
    > > be rescheduled and when this thread call preempt_check_resched() in
    > > next time it will be rescheduled.
    > >
    > > Of course, preemption also must be enabled by preempt_enable().

    >
    > As I understand it, so long as you properly select preemption when you
    > build the kernel, it should be enabled by default and no special calls
    > should be needed. You only need to call 'preempt_check_resched' if
    > preemption might be disabled and you still want to be able to be
    > preempted at a particular point.
    >
    > I am not 100% sure, but this is my understanding of the code and the
    > documentation.
    >
    > DS



  9. Re: Preemptive linux


    Binary wrote:

    > Will this challenge the driver developer, such as reentrant function
    > handling.
    >
    > Any comments?


    It rarely makes much difference because the issues with pre-emption are
    more or less identical to the issues with SMP.

    Imagine if you write some code that first does X, then does Y. There is
    some other code, Z, that has issues if it runs between X and Y. How is
    a single CPU doing "X, pre-empt to Z, then Y" any different from
    another CPU doing Z after you finish X but before you start Y?

    There are differences at low-level, of course. But Linux already takes
    care of that in its code for things like spinlocks.

    DS


  10. Re: Preemptive linux

    many driver are wrote for UP before, such as a global variable is
    accessed without lock.

    David Schwartz wrote:
    > Binary wrote:
    >
    > > Will this challenge the driver developer, such as reentrant function
    > > handling.
    > >
    > > Any comments?

    >
    > It rarely makes much difference because the issues with pre-emption are
    > more or less identical to the issues with SMP.
    >
    > Imagine if you write some code that first does X, then does Y. There is
    > some other code, Z, that has issues if it runs between X and Y. How is
    > a single CPU doing "X, pre-empt to Z, then Y" any different from
    > another CPU doing Z after you finish X but before you start Y?
    >
    > There are differences at low-level, of course. But Linux already takes
    > care of that in its code for things like spinlocks.
    >
    > DS



  11. Re: Preemptive linux


    Binary wrote:

    > many driver are wrote for UP before, such as a global variable is
    > accessed without lock.


    Yes, but you're talking long before the kernel was made pre-emptive.
    All significant drivers have supported SMP for ages.

    DS


+ Reply to Thread