Mailinglist Archive: opensuse (3182 mails)
| < Previous | Next > |
Re: [opensuse] Why I don't upgrade often
- From: Randall R Schulz <rschulz@xxxxxxxxx>
- Date: Wed, 14 Mar 2007 22:49:00 -0700
- Message-id: <200703142249.00362.rschulz@xxxxxxxxx>
On Wednesday 14 March 2007 20:53, M Harris wrote:
> On Wednesday 14 March 2007 23:29, Randall R Schulz wrote:
> > > I was just trying to kill some processes on a Win2003 system
> > > today and had to wait for the kernel to finish some tasks before
> > > it would die.
> >
> > That can happen on Linux, too. Try to kill a process in a 'D' wait
> > state. It's not possible. Extended duration of a D wait does imply
> > a bug (usually in a disk or file system driver), but it happens.
>
> Whether a user at root level can kill a process is not necessarily a
> test of how well preemptive multitasking has been implimented.
The problem I'm referring to is unrelated to access control privileges.
The kernel simply will not allow a signal to interrupt a process that
is waiting at or below priority 0 (not to be confused with nice level
0). This is because the integrity of the kernel's shared data
structures depends on such waits being uninterruptable. They're used
only for things like disk I/O (hence the signifier 'D' in ps output),
but bugs or dropped interrupts can cause them to persist indefinitely.
When that happens, the user-level process cannot be terminated no
matter what you do (short of poking kernel memory in some extremely
well-crafted manner, I suppose).
> However, if the kernel (or other ring zero processes) receive more
> time slice than other processes on the system then there may be a
> problem... and the M$ kernel (and other ring zero processes) are
> notorious for not playing well in the preemptive sandbox.... which
> means, well, it ain't truly preemptive--- I will admit that they
> have made huge strides from the early windoze days... but they are no
> match for the linux kernel... no way.
In both cases we're talking about bugs interfering with normal process
scheduling, not the design of the operating system kernels, both of
which (Linux and Windows at least from NT onward) are genuinely
preemptive, time-sliced, interrupt-driven and _non-_cooperatively
scheduled.
> M Harris <><
Randall Schulz
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
> On Wednesday 14 March 2007 23:29, Randall R Schulz wrote:
> > > I was just trying to kill some processes on a Win2003 system
> > > today and had to wait for the kernel to finish some tasks before
> > > it would die.
> >
> > That can happen on Linux, too. Try to kill a process in a 'D' wait
> > state. It's not possible. Extended duration of a D wait does imply
> > a bug (usually in a disk or file system driver), but it happens.
>
> Whether a user at root level can kill a process is not necessarily a
> test of how well preemptive multitasking has been implimented.
The problem I'm referring to is unrelated to access control privileges.
The kernel simply will not allow a signal to interrupt a process that
is waiting at or below priority 0 (not to be confused with nice level
0). This is because the integrity of the kernel's shared data
structures depends on such waits being uninterruptable. They're used
only for things like disk I/O (hence the signifier 'D' in ps output),
but bugs or dropped interrupts can cause them to persist indefinitely.
When that happens, the user-level process cannot be terminated no
matter what you do (short of poking kernel memory in some extremely
well-crafted manner, I suppose).
> However, if the kernel (or other ring zero processes) receive more
> time slice than other processes on the system then there may be a
> problem... and the M$ kernel (and other ring zero processes) are
> notorious for not playing well in the preemptive sandbox.... which
> means, well, it ain't truly preemptive--- I will admit that they
> have made huge strides from the early windoze days... but they are no
> match for the linux kernel... no way.
In both cases we're talking about bugs interfering with normal process
scheduling, not the design of the operating system kernels, both of
which (Linux and Windows at least from NT onward) are genuinely
preemptive, time-sliced, interrupt-driven and _non-_cooperatively
scheduled.
> M Harris <><
Randall Schulz
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx
| < Previous | Next > |