Normally, memory that is used all the time does not get
swapped out. If you use X while the machine is swapping,
you will normally see lots of little delays, not
one longe freeze. So this may have been something else.
This scenario seems to require only moderate swap. There
may be another explanation, that require more X knowledge
than I have:
Some windowing systems give apps the opportunity of
blocking the entire windowing system while doing stuff.
This is usually only used for "system modal dialogs" and
for very quick operations that need to stop all other user interaction.
I don't know to what extent this is possible in X, but if
it is, then the door is open for badly written apps to
to stupid things like load a 380M file while the user interface
is blocked. A well-designed app should do such lengthy jobs
without blocking everything else, so the user can do other stuff
while the machine works. Note that any io-operation _might_ be
lengthy - even a 50-byte file could reside on a network file
system on a server located in a different continent.
You may want to write to xjed developers, perhaps they
can do something about this. Like loading the
file in the background, perhaps.
[...]
The interesting question is whether this is a swapping problem that can
be solved
by kernel fixing, or if it merely is a problem with the design of the X
server.
In the latter case you need to contact x.org developers instead. xjed
developers
can probably work around the problem too, although that would to be
unnecessary
if both the kernel and the x server were ideal.
A test you can do:
* Start up X as usual and log in
* Switch to the console (ctrl+alt+F2)
* Log in on the console, with the same user as you have in the X session.
* Give the command "export DISPLAY=:0" (without the quotes)
* Start xjed with the big file, from the console. You won't see it there,
it will show itself in the X session instead. Make sure you start it
in the
background, i.e.: "xjed bigfile & "
The machine should now start using the disk, loading the big file and
swap as usual.
Now try doing stuff in the console shell. Try various commands like
ls, view some text files in "vim", things like that.
Now, if your console session is just as blocked and sluggish as the X
session usually
gets - then it is a kernel/swapping problem.
If console usage is fine (or perhaps jerky uneven response but no
prolonged freeze)
then the kernel is ok and your problem is in the X server.
You can switch back to X after the test, usually something like ALT+F7.
Helge Hafting
--
