Linux multitasking
Christopher R. Carlen
I would like to understand why I experience certain kinds of behavior
using Linux. I have Suse 7.3 with 2.4.10.
I find that it is possible running programs in X, particularly Netscape,
that the program can get stuck. When it does this, the pointer will not
operate on X. That is, if I try to move out of Netscape's window I
can do so, but then no other applications respond either. The KDE panel
doesn't respond. Nothing. Not until Netscape recovers, or I kill it by
going to a console (the keyboard fortunately responds).
The pointer stays stuck in a funny shape when this happens, so it
doesn't undergo the usual changes when moving across windows, etc. When
this happens I know that there is the problem I described.
My question is how can this happen? Perhaps a definition of "preemptive
multitasking" would be useful here.
My conception of it is that there is a hardware timer interrupt that
periodically returns control to the kernel from any userland process.
Once the kernel is in control, it switches control to another process.
The processes thus get timeslices. I realize it is complicated by
priority levels. But it seems that in a preemptive system, it would be
impossible for any hung program to cause the input devices to fail to
respond.
Of course, the input devices are responding in my situation, but their
input (actually just the mouse) doesn't go to any other program except
the stuck one.
I suppose this is really a problem with the architecture of X. It is
apparent that the kernel is multitasking.
But I would appreciate hearing someone do some narration about what goes
on under the hood, that might lend some understanding to why this kind
of thing can happen.
Also, when doing very intensive file or network IO, like when I do a
file search or start VMware, the system can become very sluggish. 99%
of CPU cycles wind up going to the offending task. How can this happen?
Is a process that runs as root the only one that can do this?
Any insights appreciated.
--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crc...@sandia.gov
Richard Pitt
On Fri, 29 Mar 2002 08:12:42 -0800, Christopher R. Carlen wrote:
> Hi:
>
> I would like to understand why I experience certain kinds of behavior
> using Linux. I have Suse 7.3 with 2.4.10.
>
> I find that it is possible running programs in X, particularly Netscape,
> that the program can get stuck. When it does this, the pointer will not
> operate on X. That is, if I try to move out of Netscape's window I
> can do so, but then no other applications respond either. The KDE panel
> doesn't respond. Nothing. Not until Netscape recovers, or I kill it by
> going to a console (the keyboard fortunately responds).
>
> The pointer stays stuck in a funny shape when this happens, so it
> doesn't undergo the usual changes when moving across windows, etc. When
> this happens I know that there is the problem I described.
Don't know the exact problem here - but have had it myself on older
version of Netscape. This is X problem, not multi-tasking at the OS level.
In this case X switches the pointer output (mouse in this case) from
program to program based on where it is in relation to the images on the
screen (as you move from window to window, the "focus" of the pointer
changes to each underlying program in turn. I'll leave it to one of the
GUI gurus to explain why/how it can get wedged on a particular program.
> My question is how can this happen? Perhaps a definition of "preemptive
> multitasking" would be useful here.
General description - look at the source for more definitive details:
Linux kernel maintains a list of processes and their states. (see top and
vmstat for a look at what is going on) - when a process becomes "runable"
i.e. has input and wants to do something - the processor gives it control
of the CPU for the shorter of: what it wants, or 1 clock tick. So the
program can reliquish the CPU before the clock tick, or the kernel can
grab it back at the clock tick. The kerenel then gives the next runable
process the same opportunity. If there are no runable processes, the CPU
goes into a "wait loop" where it effectively puts the CPU to sleep (on
Intel architecture this means executing NOP which can lower CPU power
drain quite a bit thereby saving battery on laptops for example) - an
interrupt wakes it if something happens.
There is a fudge factor called "niceness" -scale of -20 to +20 with -20
being high priority and +20 being low priority.
The kernel schedules high priority processes to run before lower priority
is given a chance. Kernel runs with highest priority (so it can hog the
CPU quite a bit if it wants to)
The kernel can (and does) change the niceness of low priority processes
based on whether they have had a "fair" share of CPU resources in recent
time - so eventually all processes will run. This process happens over
seconds, not microseconds.
When a process is started, or at other times using a tool called renice,
its niceness level is set at some value. (nice --20 bash will give you a
highest priority shell prompt - great for debugging runaway systems if you
can get it to run at all - takes patience on a truly wedged system). root
can create high priority processes - others can only lower their priority.
> My conception of it is that there is a hardware timer interrupt that
> periodically returns control to the kernel from any userland process.
> Once the kernel is in control, it switches control to another process.
> The processes thus get timeslices. I realize it is complicated by
> priority levels. But it seems that in a preemptive system, it would be
> impossible for any hung program to cause the input devices to fail to
> respond.
Correct. there is a heartbeat timer. As noted, the input device is
responding - but X is not correctly dealing with the input focus change.
Different from the kernel.
> Of course, the input devices are responding in my situation, but their
> input (actually just the mouse) doesn't go to any other program except
> the stuck one.
>
> I suppose this is really a problem with the architecture of X. It is
> apparent that the kernel is multitasking.
Right.
> But I would appreciate hearing someone do some narration about what goes
> on under the hood, that might lend some understanding to why this kind
> of thing can happen.
> Also, when doing very intensive file or network IO, like when I do a
> file search or start VMware, the system can become very sluggish. 99%
> of CPU cycles wind up going to the offending task. How can this happen?
> Is a process that runs as root the only one that can do this?
>
> Any insights appreciated.
I run VMware and have xosview locked on my screen so I see exactly how it
behaves - have been watching it for over 3 years.
On my system (1.2GHz Athalon, 1.2G RAM) the system is responsive in
loading VMware up to the point where the amount of RAM VMware wants is
more than what is avaialble - then the system pages to the swap file
quite a bit until everything is in place at which time the system is
fine.
If the Windows system needs to check its disk due to problem shutdown,
this will beat up the Linux system too since it is a virtual disk (in my
case).
If the Windows system runs Norton (as mine does) and you have not
recently done a virus scan, this will start up shortly after boot and
beat up the disk.
All of this causes the CPU to show lots of SYS activity as the VMware
system calls for disk I/O - note that I'm using emulated IDE drives. I
have not tried emulated SCSI drives yet - IDE is very CPU intensive (on
the Windows side as well as on the Linux side) which may be the reason
for the high SYS levels during intensive virtual disk I/O.
Note that on my system I also have a couple of X-windows terminals (old
CPUs with NFS booted version of Linux running diskless) and when the
screen saver on them kicks in I see lots of CPU too - but all NICE'd down
so it doesn't affect the running of the rest of the box.
xosview is great for visualizing what is going on.
Hope this helps
richard
--
Richard C. Pitt C.E.O. Belcarra Messaging Corp.
ric...@belcarra.com 604-644-9265 www.belcarra.com
Embedded Linux Systems: Design, Creation, Integration
Specializing in USB, Flash, and all things TCP/IP
Floyd Davidson
>Hi:
>
>I would like to understand why I experience certain kinds of behavior
>using Linux. I have Suse 7.3 with 2.4.10.
>I find that it is possible running programs in X, particularly Netscape,
>that the program can get stuck. When it does this, the pointer will not
> operate on X. That is, if I try to move out of Netscape's window I
>can do so, but then no other applications respond either. The KDE panel
>doesn't respond. Nothing. Not until Netscape recovers, or I kill it by
>going to a console (the keyboard fortunately responds).
[big snip]
Richard Pitt provided a rather detailed look at what Linux does
and how the behavior you see happens.
But I think it may have masked some practical answers on what to
do about it.
I can't be sure if your system really is cpu bound, or if it is
just simply being forced into paging by a lack of RAM. Either
one could cause what you describe, and in particular Netscape
and KDE are both resource hogs that lead to either or both
problems.
Netscape in particular has a bug that occasionally causes it to
just suck up all the available virtual memory a system has. But
regardless, if your system doesn't have enough RAM it will be
paging things out to swap space. Of course, if you run out of
swap space too, then things *really* look wedged!
The most obvious solution, is to run xsysinfo or xosview and
watch what is going on when your box emulates a glacier. If it
needs more RAM or more swap, you won't have to guess.
But in the long run there is one other way to help avoid this
too. Dual processor motherboards, and relatively inexpensive
cpu's to go in them, are commonly available. Two cpu's at some
given speed simply will not run single threaded programs at
twice the speed of a single cpu... but, while wedging one cpu
may be common, wedging two isn't. That means keyboard
responsiveness is percieved to be much better with
multi-processor systems. So is X, because at any given time X
will be on one cpu and the cpu intensive program you run will be
on the other cpu.
My firewall and my laptop aren't SMP boxes, put it that way.
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Dan Espen
> You have a pretty good idea of what is happening already it seems.
>
> On Fri, 29 Mar 2002 08:12:42 -0800, Christopher R. Carlen wrote:
>
> > Hi:
> >
> > I would like to understand why I experience certain kinds of behavior
> > using Linux. I have Suse 7.3 with 2.4.10.
> >
> > I find that it is possible running programs in X, particularly Netscape,
> > that the program can get stuck. When it does this, the pointer will not
> > operate on X. That is, if I try to move out of Netscape's window I
> > can do so, but then no other applications respond either. The KDE panel
> > doesn't respond. Nothing. Not until Netscape recovers, or I kill it by
> > going to a console (the keyboard fortunately responds).
> >
> > The pointer stays stuck in a funny shape when this happens, so it
> > doesn't undergo the usual changes when moving across windows, etc. When
> > this happens I know that there is the problem I described.
>
> Don't know the exact problem here - but have had it myself on older
> version of Netscape. This is X problem, not multi-tasking at the OS level.
> In this case X switches the pointer output (mouse in this case) from
> program to program based on where it is in relation to the images on the
> screen (as you move from window to window, the "focus" of the pointer
> changes to each underlying program in turn. I'll leave it to one of the
> GUI gurus to explain why/how it can get wedged on a particular program.
Sounds to me like Netscape grabbing the X server.
Try Mozilla, Opera, or some other browser.
codesaur
>Hi:
>
>I would like to understand why I experience certain kinds of behavior
>using Linux. I have Suse 7.3 with 2.4.10.
>
>I find that it is possible running programs in X, particularly Netscape,
>that the program can get stuck. When it does this, the pointer will not
> operate on X. That is, if I try to move out of Netscape's window I
>can do so, but then no other applications respond either. The KDE panel
>doesn't respond. Nothing. Not until Netscape recovers, or I kill it by
>going to a console (the keyboard fortunately responds).
>
>The pointer stays stuck in a funny shape when this happens, so it
>doesn't undergo the usual changes when moving across windows, etc. When
>this happens I know that there is the problem I described.
>
>My question is how can this happen?
If can happen IFF the X server has exclusive control of the graphics
device. In Windows it's my understanding that the kernel has
exclusive control of the graphics device. Of course in Windows it
doesn't matter because systems just "hang" anyway. For example, as I
was typing this, my system hung for about 1/4 second while it was
performing some disk operation, presumably page-saving. It should
have been doing the page-saving, that's fine, but it shouldn't have
hung my keboard.
The solution to this architectural defect is to define the operating
system's programming interface to be non-preemptive , and run all
processes under a multi-threaded micro-kernel. You are therefore
assured that all working applications give up control occasionally,
even if they are (possibly loadable) kernel components running at a
high priority, and you also ensure that all processes including kernel
components share time according to the desired algorithm.
>Perhaps a definition of "preemptive
>multitasking" would be useful here.
>
>My conception of it is that there is a hardware timer interrupt that
>periodically returns control to the kernel from any userland process.
Nowadays I guess we do have those clock interrupts; we also have those
device interrupts. Any of them will wake the micro-kernel up and then
the micro-kernel should go through its normal algorithm for selecting
the nest dispatchable task. An object-oriented kernel allows us to
choose different dispatching algorithms dynamically based on changing
load conditions.
>Once the kernel is in control, it switches control to another process.
>The processes thus get timeslices. I realize it is complicated by
>priority levels. But it seems that in a preemptive system, it would be
>impossible for any hung program to cause the input devices to fail to
>respond.
Not if exclusive control of the input device is granted to the
application, that's why in any usable operating system will dedicate
exclusive control of every device to a specific kernel process which
acts as a multi-threaded server, and users of the device can compete
equally for its use; that way X can/could operate independently of
system-oriented controls.
>Of course, the input devices are responding in my situation, but their
>input (actually just the mouse) doesn't go to any other program except
>the stuck one.
>
>I suppose this is really a problem with the architecture of X. It is
>apparent that the kernel is multitasking.
It's a design problem with the level of the operating system
immediately below X.
>But I would appreciate hearing someone do some narration about what goes
>on under the hood, that might lend some understanding to why this kind
>of thing can happen.
I've never developed for Linux, I don't even have it installed at the
moment, other than as a SlackWare bootable directory. I downloaded
the LinuxFromScratch packages, but never got around to installing
them; I noticed that LFS will have a CD image that will automate the
install procedure. THAT is where I want to start.
>Also, when doing very intensive file or network IO, like when I do a
>file search or start VMware, the system can become very sluggish. 99%
>of CPU cycles wind up going to the offending task. How can this happen?
Crappy processor allocation algorithm.
> Is a process that runs as root the only one that can do this?
>
>Any insights appreciated.
Good luck.