Messages in this thread | | | Date | Fri, 24 Feb 2006 00:42:13 +1100 | From | David Chinner <> | Subject | Re: udevd is killing file write performance. |
| |
On Thu, Feb 23, 2006 at 06:56:39AM -0600, Robin Holt wrote: > On Wed, Feb 22, 2006 at 12:05:47PM -0800, Andrew Morton wrote: > > Robin Holt <holt@sgi.com> wrote: > > > > > > Let me reiterate, I know _VERY_ little about filesystems. Can the > > > dentry->d_lock be changed to a read/write lock? > > > > Well, it could, but I suspect that won't help - the hold times in there > > will be very short so the problem is more likely acquisition frequency. > > > > However it's a bit strange that this function is the bottleneck. If their > > workload is doing large numbers of reads or writes from large numbers of > > processes against the same file then they should be hitting heavy > > contention on other locks, such as i_sem and/or tree_lock and/or lru_lock > > and others. > > > > Can you tell us more about the kernel-visible behaviour of this app? > > I looked at a little more of the output. All I have to go on is a few > back traces generated by kdb of the entire system a few seconds apart. > > In all of the traces, the first chunk of cpus are the only ones doing > writes. I have not counted exactly, but I think it is around 32. There > may be more or less, but that is the feeling (sometimes they are doing > reads as well).
Robin, is the app doing direct or buffered I/O?
Cheers,
Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group - 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/
| |