Linux-kernel mailing list archive 1999-20,: buffer-2.2.9-E.gz

# buffer-2.2.9-E.gz

Andrea Arcangeli (andrea@suse.de)
Tue, 18 May 1999 23:50:53 +0200 (CEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Ian Eure: "Re: most stable 2.2.x kernel?"
- Previous message: alex.buell@tahallah.demon.co.uk: "2.3.3 Total Lock-Up"

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/

- Next message: Ian Eure: "Re: most stable 2.2.x kernel?"
- Previous message: alex.buell@tahallah.demon.co.uk: "2.3.3 Total Lock-Up"