Re: 2.4.18: lru_list_lock contention in write_unlocked_buffers()

Hi,

> > 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.
<snip>
> 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).

thank you.
Putting the same modification in __block_fsync reduce the contention
very much.

The other solution might be adapting nfract value to match the memory size
to avoid lru_list growing too long.

Best regards.
--
NOMURA, Jun'ichi <[e-mail], [e-mail]>
Enterprise Linux Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.

--- linux/fs/block_dev.c
+++ linux/fs/block_dev.c
@@ -174,7 +174,7 @@ static int __block_fsync(struct inode * 
 	int ret, err;
 
 	ret = filemap_fdatasync(inode->i_mapping);
-	err = sync_buffers(inode->i_rdev, 1);
+	err = sync_buffers(NODEV, 1);
 	if (err && !ret)
 		ret = err;
 	err = filemap_fdatawait(inode->i_mapping);
--- linux/fs/buffer.c
+++ linux/fs/buffer.c
@@ -384,7 +384,7 @@ int fsync_no_super(kdev_t dev)
 
 int fsync_dev(kdev_t dev)
 {
-	sync_buffers(dev, 0);
+	sync_buffers(NODEV, 0);
 
 	lock_kernel();
 	sync_inodes(dev);