Messages in this thread | | | Date | Wed, 12 May 1999 15:48:26 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | 2.2.8_andrea1.bz2 |
| |
I released a new andrea-patch against 2.2.8. This new one has my new wake-one on accept(2) strightforward code (but to get the improvement you must make sure that your apache tasks are sleeping in accpet(2), a strace -p `pidof apache` should t you that).
It has my latest reschedule_idle (just run a proggy that does `main() { for(;;); }' in background while monitoring with xosview, to see the difference). Plus one minor fix for the SCHED_YIELD thing from Ingo (not from me).
Now I use the swap cache for doing async swapout of shm memory and this in turn mean that I am been allowed to kill the swap-lockmap.
I fixed and improved the swap clustering swapout algorithm (btw, the highbits and lowerbits handling is still buggy in the stock kernel, sure not a big problem but it's a bug anyway ;).
There's my VM-lru code + my buffer.c redesign.
It has my semaphore and disable/enable_bh longstanding SMP race fixes.
Plus many other things......
Since it's always been rock solid under any kind of load, now I would like to start proposing most of my code for inclusion into 2.3.x ;). (except the wakeone thing that can be implemented more efficiently (without browsing the whole waitqueue) but breaking the wait queue interface, I think my approch is the right one for 2.2.x and I wanted to address only the overscheduling issue)
Linus, can I start sending you my new VM/buffer code?
BTW, I seen the buffer.c changes of 2.2.8. You have killed (not fixed ;) flushtime. At least you could have removed also flushtime from the struct buffer_head to avoid wasting time in useless initializations ;). In 2.2.8 `update` does only a little sync of ndirty buffers every 5 sec (the 5 sec depends by -f option of update). This is _not_ how things should go according to me. And syncing back inodes and superblock has to be done _only_ for integrity of the filesystem (not for the kernel stability) and so it's `update` that has to do that, not bdflush. If nobody will do that we'll run faster but if the system will crash with some filesystem mounted we'll be in troubles...
I also don't agree with syncing back some dirty buffer every 5 sec via bdflush. That's sure _not_ the way to get performances. If the system is idle and nobody is going to grow dirty buffers there's no need to flush them to disk (unless they are very old, and the only reasons to flush old buffers is trying to get filesystem integrity after a crash without losing too much caching performances). And _only_ in the case we'll then go low on memory it's shrink_mmap that has to flush dirty buffers to disk.
So I rejected all the buffer.c changes included in 2.2.8 (I bet 2.2.8 will be faster then 2.2.7 simply because update can't harm performances anymore because sync_old_buffers don't know about flushtime anymore ;) and I think my approch will be still slightly faster than 2.2.8 (if somebody would do a benchmark between 2.2.8 and 2.2.8_andrea1.bz2 while writing a lot of data to disk in the same place many times (like the gdbm case) I would be glad).
Comments?
Andrea Arcangeli
- 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/
| |