"David S. Miller" wrote:
>
> Are you seeing "contention" for the lock? That is what matters.
>
There is little contention (~ 1%), but I have a dual cpu computer, not
an 8-way server.
> lru_list lock is the longest held mainly because it is the outermost
> lock in the buffer cache locking hierarchy.
>
Yes, the problem is that gtcd polls /dev/cdrom, and that every close()
call calls __invalidate_buffers(). __invalidate_buffers() must walk the
complete buffer chain, and as I wrote the buffer chain contained ~
100000 entries.
Either we ignore the problem, or we could add a per-kdev_t linked list.
I have another problem with flush_dirty_buffers():
flush_dirty_buffers() quits as soon as it finds the first buffer where
b_flushtime has not yet expired.
I can't find the code that enforced this chronological ordering, esp.
since the time until a buffer must be written to disk if different for
metadata blocks and normal blocks.
[just grep for b_flushtime, there is no sort algorithm]
-- 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 : Sat Feb 19 2000 - 11:22:52 EST