Messages in this thread | | | Date | Tue, 18 May 1999 23:50:53 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | buffer-2.2.9-E.gz |
| |
I have a new update about by buffer patch. The difference between buffer-2.2.9-E.gz and the previously posted buffer-2.2.9-C.gz are:
o now I set flushtime only when the buffer goes from a clean to a dirty state. Stefan Monnier convinced me that to be more safe after a crash we should write an update of the dirty buffer over the time. This mean decrasing performances in rewriting to the same place though... I also thought at an exponential fading of the flushtime, but after all a sync of the buffer over the time seems not to harm too much performances at least in the normal usage.
o now I killed uptime but in a way that will sure give back to us the taskslot ;).
o some major redesign of mark_buffer_dirty. It seems to me that flushing buffers by hand does not provide good iteractiveness. It seems that when there are many tasks all sleeping in wait_for_request then kflushd always fill the request pool before other tasks have a chance to get rescheduled... maybe because the wakeup is LIFO (even if it's not one wake-one there...).
o my new trashing_IO heuristic in the task_struct (it's the brother of my trashing_mem heuristic that I always use in GFP of andrea patches). This way the task that is trashing I/O will block in a lower stage and will allow all other tasks to not block in mark_buffer_dirty().
o new hashfn math from Peter Steiner and Chuck Lever. To complete its integration in the kernel I added a bh_hash_bits initialized at hash_init time.
o improved sync_old_buffer() by blocking after the first dirty buffer is too young. We can avoid doing an browse of all the dirty list because we put newer buffers always at the end of dirty list and we never roll the dirty lru list.
o probably some other minor thing.
The new patch against clean 2.2.9 is placed here:
ftp://e-mind.com/pub/andrea/kernel-patches/buffer-2.2.9-E.gz
If you try it please feedback.
Thanks! ;)
For the record the old patch buffer-2.2.9-C.gz was just doing:
o flushtime handling redesigned: every time we touch a buffer we return to set its timeout (simple no? ;)
o dropped all cli/sti pairs, replaced the end_io_async irq/SMP synchronization with a per-pagemap spinlock (to scale far better) and removed all locking from the reuse_list handling using smart write ordering and bogus-pointers-loops
o reordered buffer heads members to be more friendly with cachelines
o fastcall for some fast path
o my dynamic hashtable code
o avoids not necessary run_task_queue and adds needded ones
o in some loop we can allow the current bh to be freed after a sleep (no need to bh->b_count++, only need to bhnext->b_count++)
o cleanup of lists and hash insertion/deletion
o enforced by design that a buffer must always be mapped in a hashtable or otherwise it means that it's a freeable (from shrink_mmap) and queued in the freelist.
o fixed races in set_blocksize/invalidate_buffers and now both functions also put invalidated buffers in the freelist to improve performances (the race could happens if next would be refiled while we slept)
o fixed a race in show_buffers: we must check if buffer.c may be playing with our freelist (or was in the middle of some list operation) before browsing the lru lists from the keyb irq
o try_to_free_buffers() start I/O on the collected buffers directly
o all tasks start I/O directly if there are too many dirty buffers.
o kflushd only takes the I/O pipeline full if there are many dirty buffers (no other works for it)
o minor problem in ll_rw_blk about stats of write/read ahead requests fixed
Andrea Arcangeli
PS. A new 2.3.3_andrea1.bz2 is coming out with the new buffer stuff plus other things but against 2.3.3.
- 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/
| |