Re: 2.4.18: lru_list_lock contention in write_unlocked_buffers()

[Andrew Morton <akpm@digeo.com>]

j-nomura@ce.jp.nec.com wrote:
>
> Hello,
> 
> when I run mkfs while doing other large file I/O in parallel,
> the system response becomes terribly bad on 2.4.18 kernel.
> (probably on other 2.4 kernels also)
> 
> I found there are hard contention on lru_list_lock, which is mostly held
> by write_unlocked_buffers().
> It happens only on large memory machine because lru_list can grow very long
> and write_some_buffers() scans the long list from head on each call.
> 
> Lowlatency patch in aa tree did not help this situation.
> 
> The patch below is hasty workaround for it.
> Any comments, or suggestions to better fix?
> 

I don't think there's a sane fix for this in the 2.4 context.

What you can do is to convert fsync_dev() to sync _all_ devices and not just
the one which is being closed.

It will take longer, but it converts the O(n*n) search into O(n).

diff -puN fs/buffer.c~a fs/buffer.c
--- 24/fs/buffer.c~a	2003-04-02 00:21:39.000000000 -0800
+++ 24-akpm/fs/buffer.c	2003-04-02 00:21:51.000000000 -0800
@@ -343,6 +343,7 @@ int fsync_no_super(kdev_t dev)
 
 int fsync_dev(kdev_t dev)
 {
+	dev = NODEV;
 	sync_buffers(dev, 0);
 
 	lock_kernel();

_