Disk activity
=============
Something's changed. Can't say whether it's the main tree changes or
Rik's mm changes (I haven't tried plain 2.1.131).
I'm not using any swap either (well, 16k on a 64MB system). It feels
faster somehow anyway.
Well, apart from Squid which still spends a few minutes grinding away at
the disk when it starts. I would like to find a way to fix this, it's
probably the most thrashy thing my disk has to handle and it does slow
down everything else for a while quite significantly.
Netscape still hits the disk very hard when it starts, and takes what
seems like just as long. Netscape is pretty quick to start the second
time though (about 3 seconds), so it's definitely a paging thing. Is
there anything which could be done with paging
read-ahead/read-behind/read-cleverer to make Netscape not thrash the
disk when it starts?
Scheduling
==========
Something's changed in the scheduling, because the behaviour starting X
is different:
I start four xclocks of different colours and timezones, which are
mapped into an FvwmButtons window along with their names. Most of the
time this works fine, but sometimes the clocks map to the wrong labels
because the way FvwmButtons captures the clock windows depends on their
timing.
With 2.1.131 + Rik's VM patch, almost every attempt to start the clocks
gets them in the wrong order. I mean, I had to try about 16 times until
they got it right. Something's different!
The clocks do seem to map & unmap faster than before, but that might
just be me and the warm, rosy glow of using a fresh new kernel.
Mail over NFS
=============
The losing-mail-over-NFS thing I've been mentioning recently should be
ok now, though I haven't tried it. That is, _if_ you use fcntl()
locking; just dot-locking is *not* good enough unless you disable
cacheing. (The locking method used by default depends on which
distribution you're using).
>From a first reading of the source, 2.1.131's fix for the above isn't
perfect in some rare cases, and if you're really unlucky you can end up
with a stale lock on the mail spool. I'll be testing and chasing up the
finer points shortly. But the gaping hole is fixed.
Enjoy,
-- Jamie
-
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/