Messages in this thread Patch in this message | ![/](/images/icornerl.gif) | | Date | Wed, 2 Apr 2003 00:23:17 -0800 | From | Andrew Morton <> | Subject | Re: 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/
| ![\](/images/icornerr.gif) |