> > On Sat, May 31, 2014 at 03:45:36PM +0900, Namjae Jeon wrote: > > ext4 file write is already serialized with inode mutex. > > Right, I had forgotten about that. The case where we really care > about parallel writes is in the direct I/O case, and eventually I'd > like for us to be able to support non-overwriting/non-isize-extending > writes in parallel but we're not there yet. Okay. > > > So I think the impact of adding another lock will be very very less.. > > When I run parallel write test of fio to prove it, I can not see the difference on w/wo > i_write_mutex. > > If there is an impact, it won't show up there. Where it will show up > will be in high scalability workloads. For people who don't have the > half-million dollars (and up) expensive RAID arrays, a fairly good > facsimile is to use a > 16 core system, preferably a system at least 4 > sockets, and say 32 or 64 gigs of memory, of which you can dedicate > half to a ramdisk. Then run the fio scalability benchmark in that > scenario. That way, things like cache line bounces and lock > contentions will be much more visible when the system is no longer > bottleneck by the HDD. Yes, Right. I agree that result should be measured on high-end server as you pointed again. Unfortunately I don't have such equipment yet.. > > > Yes, Right. We can use shared lock to remove a little bit lock contention in ext4 file write. > > I will share rwsem lock patch.. Could you please revert i_write_mutex patch ? > > So the shared lock will help somewhat (since writes will be far more > common than fallocate calls) but I suspect, not all that much. And if > I revert the i_write_mutex call, now, we won't have time to replace it > with a different patch since the merge window is already open. > > And since this patch is needed to fix a xfstests failure (although > it's for collapse range in data journalling mode, so not a common > case), if we can't really see a performance loss in the much more > common server configurations, I'm inclined to leave it in for now, and > we can try to improve performance in the next kernel revision. IMHO, If our goal is to solve the problem of xfstests, we can use only "ext4: fix ZERO_RANGE test failure in data journalling" patch without i_write_mutex patch. And we can add lock for fallocate on next kernel after checking with sufficient time. Thanks! > > What do other people think? > > - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
