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/