Messages in this thread | | | Date | Mon, 7 Dec 1998 00:51:45 +0000 | From | Jamie Lokier <> | Subject | 2.1.131 first impressions |
| |
I've just switched from 2.1.129 to 2.1.131 + Rik's "fastest VM system" patch, and I have to say, nice!
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/
| |