Benno Senoner wrote:
>
> PS:
> Manfred have you tried to run your spinlocks tests on
> lowlatency-2.2.10-N6B ?
That's a specific problem of the new 2.3.4x block device close handling:
> __invalidate_buffers() is the culprit:
>
> * /dev/root was cached: 100 MB cache, 100 000 buffer heads
> * /dev/cdrom: a few weeks/days ago, someone (Andrea?) added
> invalidate_buffers() to the close() operation for block devices.
> The call is required, or we risk data loss :-(
> * gtcd calls close("/dev/cdrom") several times a second.
> * there is no per kdev_t linked list, and thus close() must walk through
> the entire block cache chain, and walking through 100 000 entries takes
> ~ 8 milliseconds :-(
>
> The big question is: should we change that? we would need a per-kdev
> linked list.
>
> Perhaps we could replace the lru list with a per-kdev_t lru list? The
> aging algorithm is broken anyway, it doesn't differentiate between
> metadata blocks and normal blocks.
>
As Dave explained, we can't thread the block cache without major
changes, but it should be possible to add per-kdev_t lru lists without
any changes outside fs/buffer.c
I've written a first patch that affects raid5, and I've sent it to Ingo
a few hour ago.
-- Manfred- 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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:25 EST