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();
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:16 EST