Very Computer

As long as I know, Kernel 2.2.x was non-preemptive. Are 2.4 and 2.5
trees still non-preemptive?

Thanks in advance.

That is incorrect. Linux has always been preemptive.
However it only preempted processes in user mode. If
a process was in kernel mode a flag was set causing
the process to give up the CPU at return to user
mode. This worked fine as long as there was not
spend too much time in kernel mode. If a long loop
was needed, the flag could be explicitly checked
with: if (current->need_resched) schedule();
However that was not done in all the locations where
it should have been done.

Quote:> Are 2.4

No changes.

Quote:> and 2.5 trees still non-preemptive?

In 2.5 there is an option to allow preemption of the
kernel. But some persons questions on the value of
this. Preemption of the kernel introduces a lot of
new problems. And in most cases, the only code it
would be valuable to preempt is poorly designed
drivers (possibly for poorly designed hardware).

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

I don't agree with this opinion. A fully preemptive kernel is much better
real time capable than a kernel that isn't preemptive at all.
In times when Linux begins to capture the embedded market, real time
capabilities are great features!
But I agree that this isn't such an important feature for Linux on the
desktop :-)

Regards, Daniel

Actually in O'Reilly's Understanding Linux Kernel it is noted that
Linux Kernel 2.2 has not been "Fully" Preemptive and the only fully
preemptive kernels of that time were Solaris and Mach.

And a "Fully" preemptive kernel is more attractive for programmers and
is a plus for the kernel

And another thing is that what is the difference between a Preemptive
Kernel and a Reenterant Kernel? Are preemptive kernels reenterant too
and vice versa?

Thanks again

As Kasper said, the kernel has always preempted processes executing in
user mode.  If not, then user processes would be able to run until they
were ready to quit, which would be a bad thing.  Processes in 2.2 and
2.4 are not preemptive in kernel mode, meaning that kernel code can run
for as long as it wishes.  However, in 2.5 code was merged in that makes
processes in kernel mode preemptible.

Quote:> And a "Fully" preemptive kernel is more attractive for programmers and
> is a plus for the kernel

Agreed, though it does cause some difficult issues, for example when
a piece of preemptible code still holds a lock.  However, the 1ms
latency times are good.  It's nice to see Linux growing up with things
like these that OSes like Solaris have had for a while.

Quote:> And another thing is that what is the difference between a Preemptive
> Kernel and a Reenterant Kernel? Are preemptive kernels reenterant too
> and vice versa?

A reentrant kernel means that >1 process may be executing in kernel mode
at any given time.

--
 josh(at)cc.gatech.edu  |  http://intmain.net:800

 191835 local keystrokes since last reboot (16 days ago)

Quote:> Actually in O'Reilly's Understanding Linux Kernel it is noted that
> Linux Kernel 2.2 has not been "Fully" Preemptive and the only fully
> preemptive kernels of that time were Solaris and Mach.

> And a "Fully" preemptive kernel is more attractive for programmers
> and is a plus for the kernel

This may be a "plus" for people that are writing certain kinds of
kernel code.  It is by no means obvious that this is /generally/
attractive to everyone in general.

Making the kernel 'totally preemptive' requires having pretty strong
guarantees about behaviour /everywhere/, and is liable to require
having quite a lot of additional locks and similar structures, thus
making the kernel bigger and slower.  

That's not an "obvious improvement."

Quote:> And another thing is that what is the difference between a
> Preemptive Kernel and a Reenterant Kernel? Are preemptive kernels
> reenterant too and vice versa?

Reentrant means that you can re-enter code arbitrarily often without
disturbing other existing instances.  This means that functions have
to allocate local "instance variables" so that multiple instances can
co-exist without *ling on one another.

Being "pre-emptive" does not mandate reentrancy, although it sure
makes implementing software easier when you have reentrancy...
--

http://www.veryComputer.com/
Why do we wash bath towels, aren't we clean when we use them?

You should be able to see latencies smaller than that even without
the preemptive kernel stuff. If you see latencies larger than 1ms
there is likely either some poor driver spending too much time in
the kernel or some driver not handling the event as fast as it
could have.

On a loaded system you might see larger latencies, but that is not
fixed by preempting the kernel, that is better handled by more
clever computation of priorities.

Quote:

> A reentrant kernel means that >1 process may be executing in kernel mode
> at any given time.

And that has indeed been possible for some time now. AFAIK that
has been possible since 2.1.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

You're right that most of the time latencies are small.  However,
in many tests it has been found that latencies often go above
1ms, even into the hundreds of ms.  Granted, this is not the common
case, but it does happen.  When used for hard realtime applications
whose requirements are that latencies should NEVER be above, say
5ms, then this just isn't good enough.  I'm not sure what the
current numbers are for 2.5, but I'm sure they're much better than
2.4.x.  Sometimes these latencies are not from a driver at all but
from kernel code which goes into a loop that repeats a large number
of times.  In these cases bad drivers are not the issue at all.  To
see some sample numbers, check here:

http://www.linuxdevices.com/articles/AT8906594941.html

As a brief summary, when combining the low-latency patch and the
preemption patch released a while back, the *maximum* latency seen
was 1.2, even when stressing the kernel for 12+ hours.  I'm not
sure if this solution in particular has been merged into 2.5, but
whatever it is I'm sure it's good.

--
 josh(at)cc.gatech.edu  |  http://intmain.net:800

 195003 local keystrokes since last reboot (17 days ago)

... and guess what?  Preemption does not guarantee that.  Period.
Never did, never will.  Linux is fundamentally not a hard-RT
kernel.  There is any number of places where (with CONFIG_PREEMPT)
you don't have any guaranteed upper bound on latency.

And where would you think that code would be? Possibly in another
driver. In most cases the fix for that problem would simply be to
insert a conditional schedule in the loop. A conditional schedule
will always be simpler to handle than preemption.

Quote:> In these cases bad drivers are not the issue at all.

That would require the loop to be in code not part of a driver.
Of course that might still be possible, I wouldn't claim to know
every loop in the kernel.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

[ . . . ]

Quote:>>When used for hard realtime applications
>>whose requirements are that latencies should NEVER be above, say
>>5ms, then this just isn't good enough.  I'm not sure what the

> ... and guess what?  Preemption does not guarantee that.  Period.
> Never did, never will.  Linux is fundamentally not a hard-RT
> kernel.  There is any number of places where (with CONFIG_PREEMPT)
> you don't have any guaranteed upper bound on latency.

I agree. But is a step in that direction. At least it is a step in the
direction of a good soft real time which is enough for a lot of
applications.

Daniel

here a little example from the scheduler code:

        list_for_each(tmp, &runqueue_head) {
                p = list_entry(tmp, struct task_struct, run_list);
                if (can_schedule(p, this_cpu)) {
                        int weight = goodness(p, this_cpu, prev->active_mm);
                        if (weight > c)
                                c = weight, next = p;
                }
        }

The length of this loop depends of the number of processes in the system.
So it is not known how long it is iterating. And there is no conditional
schedule within this loop (because a conditional schedule in the scheduler
would cause big problems ;-)).
So such code can be found not only in drivers even in the heart of
the kernel.

Regards, Daniel

And that proves what?

You obviously cannot preempt that code for the exact same reason you
cannot do a conditional schedule. Notice there is a difference
between being able to interrupt a piece of code and being able to
preempt a piece of code. In 2.4 it is certainly possible to interrupt
most parts of the kernel code, but they are not preempted. At the
return of the interrupt handler, the interrupted code will continue,
but a flag will have been enabled to cause a schedule as soon as
possible.

When it comes to tasklets, bottomhalves, and softirqs I'm not sure
in which kernel version they can be executed at once and in which
they can first be executed after a schedule. In 2.4 softirqs are
done by a kernel thread, so there a schedule will clearly be
necesarry. But being able to perform that schedule does not depend
on wether it is done by preemption or a conditional schedule.

Finally the piece of code you suggested is AFAIK one that was
removed by Ingo's new scheduler. It might not be in the mainstream
2.4 kernels, but it is in 2.5.

--
Kasper Dupont -- der bruger for meget tid p? usenet.

for(_=52;_;(_%5)||(_/=5),(_%5)&&(_-=2))putchar(_);

---[clipped]---

Quote:

> And that has indeed been possible for some time now. AFAIK that
> has been possible since 2.1.

AFAIK==?

[ . . . ]

Quote:>>         list_for_each(tmp, &runqueue_head) {
>>                 p = list_entry(tmp, struct task_struct, run_list);
>>                 if (can_schedule(p, this_cpu)) {
>>                         int weight = goodness(p, this_cpu,
>>                         prev->active_mm); if (weight > c)
>>                                 c = weight, next = p;
>>                 }
>>         }

[ . . . ]

Quote:> And that proves what?

It only shows that there are pieces of code in the kernel with an unknown
runtime. And they are not only an issue of bad driver design.

Of course, I know that it is impossible to preempt this loop. For making
the kernel fully preemptive there should have been chosen a different
design in a lot of the kernel parts. And such a design was not chosen
because there was no need for kernel preemption.
But I also want to show (as I said some postings before in this thread)
that preemption would be great and in cases like the one shown above it
could assure a better response time of the system.

Quote:> Finally the piece of code you suggested is AFAIK one that was
> removed by Ingo's new scheduler. It might not be in the mainstream
> 2.4 kernels, but it is in 2.5.

Possible. I am not familiar with the 2.5 kernel.

Regards, Daniel