lkml.org 
[lkml]   [2003]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 2.4.18: lru_list_lock contention in write_unlocked_buffers()
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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.030 / U:1.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site