Mailing List Archive

Linux Kernel constraints!
Recently(dec.) in WindowsNT magazine comparisons/similarities between
various flavours of unix and nt had come. In the same article Linux was
ignored as enterprise os on account of following kernel 'limitations' :
1. kernel is not preemptive. ie even a higher priority user thread cant
cause another thread to be swapped if the other thread is presently running
in privileged/kernel context.
2. kernel is not reentrant. ie.only one thread in kernel context at a time.
3. kernel is not multi processing in the sense that on multiprocessor
systems it will run on only one cpu at a time.
will somebody can clarify these doubts and version which enabled it to be
otherwise.
yogi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Thu, 21 Jan 1999, Yogesh Bansal wrote:
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
>
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a time.
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
>
> will somebody can clarify these doubts and version which enabled it to be
> otherwise.
The first one is true, and since they all mean the same thing, they all
are :)
At least, that's the case in 2.0.x. 2.1 (and soon 2.2) have improved
matters a fair bit as some of the "easier" targets - VM, signal-handling,
process handling - have finer grained locks around them.
However the filesystem and network stuff is still pretty single-threaded,
although this will change in time, too.
The funny thing is it's not such an issue with Linux because it has such
low latencies that it still scales better than NT on 4 way boxes.
Matthew.
- now concerned that the NT people have finalyl found some (exaggerated)
FUD that's true :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Thu, Jan 21, 1999 at 11:38:55AM +0530, Yogesh Bansal wrote:
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
As far as I know:
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
What is meant by 'swapped'? I assume it's that the CPU is taken away from
the running task(/thread). Then yes, this is true, but only would be a
problem if the kernel call would take very long time.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a time.
True only for <= 2.0 kernels.
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
True only ofr <= 2.0 kernels.
> will somebody can clarify these doubts and version which enabled it to be
> otherwise.
Hmm, I may be wrong. If I am, anyone correct me.
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Thu, 21 Jan 1999, Yogesh Bansal wrote:
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
>
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
Not true. All things that are not running with interrupts disabled can be
preempted.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a time.
Pfft. This is absurd. Every process that is blocked on I/O is _in kernel
context_. This is the way UNIX works.
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
And this is even more absurd. SMP is _symmetric_. Kernel runs on all
processors _by definition_. There may be some confusion here with respect
to lock granularity though. The very first SMP kernels had a single lock
that protected most data structures, which drastically limited kernel
concurrency. Current kernels have more fine-grained locking that allow
much better concurrency and therefore better scaling.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
Followup to: <F1C298E6C941D111A18500805F89245932C188@MIDCBDC>
By author: Yogesh Bansal <yogesh.bansal@tatainfotech.com>
In newsgroup: linux.dev.kernel
>
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
>
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a time.
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
>
> will somebody can clarify these doubts and version which enabled it to be
> otherwise.
> yogi
>
2 and 3 are just plain incorrect, although the granularity could be
improved. 1 is true, but is not a major problem in practice, except
for hard real time. As an "enterprise OS" hard real time is hardly a
requirement.
Sounds like standard WindowsNT mag. FUD to me (this mag seems to be a
major source of FUD these days.)
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
Windows NT magazine also ran an article stating all Linux programs had to
distribute their source. In the same article, they mention Oracle,
Informix, and Corel porting. So where do I download Oracle 8 source?!?
The Win NT writers either aren't bright enough to understand the LGPL,
or they're deliberately spreading misinformation.
Either way, I can't imagine any group of people less qualified to comment
on the Linux kernel.
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a time.
I believe these complaints may apply to the 2.0 kernel, due to kernel wide
spin-locks, but not 2.2
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
This I don't believe. What would be the point of SMP support if it only
used one processor at a time? So either they're looking at a kernel prior
to SMP, or they have no idea what they're talking about. Or possibly, I've
misunderstood the statement.
> will somebody can clarify these doubts and version which enabled it to be
> otherwise.
I'm by no means a kernel expert, but I didn't see any other responses.
Anyway, I might be wrong.
Justin Bradford
justin@ukans.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Thu, 21 Jan 1999, Oliver Xymoron wrote:
> On Thu, 21 Jan 1999, Yogesh Bansal wrote:
>
> > Recently(dec.) in WindowsNT magazine comparisons/similarities between
> > various flavours of unix and nt had come. In the same article Linux was
> > ignored as enterprise os on account of following kernel 'limitations' :
> >
> > 1. kernel is not preemptive. ie even a higher priority user thread cant
> > cause another thread to be swapped if the other thread is presently running
> > in privileged/kernel context.
>
> Not true. All things that are not running with interrupts disabled can be
> preempted.
by bottom half. Looks like the author means hard RT stuff.
> > 3. kernel is not multi processing in the sense that on multiprocessor
> > systems it will run on only one cpu at a time.
>
> And this is even more absurd. SMP is _symmetric_. Kernel runs on all
> processors _by definition_. There may be some confusion here with respect
> to lock granularity though. The very first SMP kernels had a single lock
> that protected most data structures, which drastically limited kernel
> concurrency. Current kernels have more fine-grained locking that allow
> much better concurrency and therefore better scaling.
kernel_lock is still there. It's held by all filesystem-related
syscalls. dcache is still not SMP-safe. Ditto for struct file -related
operations.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
In article <788c2q$r6m$1@palladium.transmeta.com>,
H. Peter Anvin <hpa@transmeta.com> wrote:
>Followup to: <F1C298E6C941D111A18500805F89245932C188@MIDCBDC>
>By author: Yogesh Bansal <yogesh.bansal@tatainfotech.com>
>In newsgroup: linux.dev.kernel
>> Recently(dec.) in WindowsNT magazine comparisons/similarities between
>> various flavours of unix and nt had come. In the same article Linux was
>> ignored as enterprise os on account of following kernel 'limitations' :
>> 1. kernel is not preemptive. ie even a higher priority user thread cant
>> cause another thread to be swapped if the other thread is presently running
>> in privileged/kernel context.
>2 and 3 are just plain incorrect, although the granularity could be
>improved. 1 is true, but is not a major problem in practice, except
>for hard real time. As an "enterprise OS" hard real time is hardly a
>requirement.
And if it is, use RT-Linux, which does have a pre-emptive kernel.
Sort of. It's actually a hard real-time microkernel that runs the entire
Linux kernel as a low-priority task. It's a hybrid solution but good enough
for a things that plain Linux isn't.
--
Zygo Blaxell (with a name like that, who needs a nick?)
Linux Engineer (my favorite official job title so far)
Corel Corporation (whose opinions sometimes differ from those shown above)
zygob@corel.ca (also zblaxell@furryterror.org)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Thu, 21 Jan 1999, Justin Bradford wrote:
> > Recently(dec.) in WindowsNT magazine comparisons/similarities between
> > various flavours of unix and nt had come. In the same article Linux was
> > ignored as enterprise os on account of following kernel 'limitations' :
>
> Windows NT magazine also ran an article stating all Linux programs had to
> distribute their source. In the same article, they mention Oracle,
> Informix, and Corel porting. So where do I download Oracle 8 source?!?
> The Win NT writers either aren't bright enough to understand the LGPL,
> or they're deliberately spreading misinformation.
> Either way, I can't imagine any group of people less qualified to comment
> on the Linux kernel.
>
> > 1. kernel is not preemptive. ie even a higher priority user thread cant
> > cause another thread to be swapped if the other thread is presently running
> > in privileged/kernel context.

nonsense...
> > 2. kernel is not reentrant. ie.only one thread in kernel context at a
time.
>
> I believe these complaints may apply to the 2.0 kernel, due to kernel wide
> spin-locks, but not 2.2
>
> > 3. kernel is not multi processing in the sense that on multiprocessor
> > systems it will run on only one cpu at a time.
>
if there is a kernel-wide lock at any given moment there can't be more
than 1 cpu running the kernel. As said 2.2 is better.
Vladimir Dergachev
> This I don't believe. What would be the point of SMP support if it only
> used one processor at a time? So either they're looking at a kernel prior
> to SMP, or they have no idea what they're talking about. Or possibly, I've
> misunderstood the statement.
>
> > will somebody can clarify these doubts and version which enabled it to be
> > otherwise.
>
> I'm by no means a kernel expert, but I didn't see any other responses.
> Anyway, I might be wrong.
>
> Justin Bradford
> justin@ukans.edu
>
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
hey, let's be serious here.
Linux works...and works...and works...ad infinitum(?)
In my opinion, it has the best minds from all around
the world making contributions to its development.
It works and will continue to work better. _i_ believe
that if we counted 'limitations' of every kernel/system
out here, linux would be among the ones having the least
'limitations' -- if not the one with the least. if you
cite 'limitation X' as making a system unsuitable for
'task Y', then all you have to do is change strategically
redifine 'X' to ensure that _your_ favorite system is
_always_ the most suitable for 'task Y'. i know linux to
be a very stable system and i think that the attribute of
stability makes a system suitable for the task of computing
aside from any 'limitation/attribute X' viewpoints (period)
brent ificanreplaceonemoreNTboxwithlinuxi'llbehappy verner
Yogesh Bansal wrote:
>
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
>
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a time.
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
>
> will somebody can clarify these doubts and version which enabled it to be
> otherwise.
> yogi
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
--
\ _|_ / GNU
\/ | \/ Certified
\_|_/ Professional
\ /
-= rYo =- Linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Thu, 21 Jan 1999, Oliver Xymoron wrote:
> > 1. kernel is not preemptive. ie even a higher priority user thread cant
> > cause another thread to be swapped if the other thread is presently running
> > in privileged/kernel context.
>
> Not true. All things that are not running with interrupts disabled can be
> preempted.
Note the 'running in kernel context'.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
On Fri, 22 Jan 1999, brent verner wrote:
> hey, let's be serious here.
> Linux works...and works...and works...ad infinitum(?)

Yes. I will make 3 statements about some the things wrong with Linux.
(1) The pyrosynchrogem is not compliant with the confuser. This makes
NT better for world-class Enterprise Solutions.
(2) The orksafagen distiller lacks treble ranges. This makes
NT better for world-class Enterprise Solutions.
(3) The modicum refuser is not reenterable. This makes
NT better for world-class Enterprise Solutions.
There are 3 more problems:
(1) Linux doesn't have a pyrosynchrogem.
(2) Linux doesn't have an orksafagen distiller.
(3) Linux doesn't have a modicum refuser.
But NT does! Of course you'll have to take my word for it because
you can't see the source-code.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
Hi,
On Thu, Jan 21, 1999 at 05:16:54PM -0600, Justin Bradford wrote:
> > 3. kernel is not multi processing in the sense that on multiprocessor
> > systems it will run on only one cpu at a time.
>
> This I don't believe. What would be the point of SMP support if it only
> used one processor at a time? So either they're looking at a kernel prior
> to SMP, or they have no idea what they're talking about. Or possibly, I've
> misunderstood the statement.
<Out of the back of my hat, here:>
In the original statement, the issue no.3 was that the /kernel/ would only
run on one CPU at a time. Which I guess is true in 2.0 with the kernel wide
spinlock. User mode code can run on the other CPUs, but generally only one
processor can be doing anything useful in kernel mode at any point in time.
Of course, a lot of this has gone away in 2.1/2.2 as I understand it.
The phrasing of the original statement is just slightly ambiguous.
--
There was a young man of St. John's
Who wanted to bugger the swans.
But the loyal hall porter
Said, "Pray take my daughter!
Those birds are reserved for the dons."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Kernel constraints! [ In reply to ]
Hi,
On Thu, 21 Jan 1999 11:38:55 +0530, Yogesh Bansal
<yogesh.bansal@tatainfotech.com> said:
> Recently(dec.) in WindowsNT magazine comparisons/similarities between
> various flavours of unix and nt had come. In the same article Linux was
> ignored as enterprise os on account of following kernel 'limitations' :
> 1. kernel is not preemptive. ie even a higher priority user thread cant
> cause another thread to be swapped if the other thread is presently running
> in privileged/kernel context.
By the same argument VMS is not an enterprise system, because above IPL
2 (the level at which the bulk of the kernel runs), you only have
cooperative, not preemptive, scheduling, and above IPL 3 you can't
reschedule at all. Same as on Linux (where the global kernel lock and
the other spinlocks impose similar scheduling constraints).
Sheesh.
This is a feature, not a problem. A fully preemptive kernel is
necessary for true realtime, NOT for a server OS. Excessive preemption
requries extra locking and it craps up the use of the CPU caches,
resulting in overall poorer throughput for a server OS.
> 2. kernel is not reentrant. ie.only one thread in kernel context at a
> time.
> 3. kernel is not multi processing in the sense that on multiprocessor
> systems it will run on only one cpu at a time.
No longer true on 2.2, and although there are still significant bits of
the kernel which _are_ serialised, these are getting reduced release by
release.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/