On Tue, Apr 17, 2012 at 11:19:26PM -0700, Allison Henderson wrote: > On 04/16/2012 10:55 AM, Zheng Liu wrote: > >Hi Allison, > > > >Currently I am trying to reduce the lock contention of direct I/O in ext4 > >because it is a bottleneck. A trivial idea is that a new fucntion is > >defined to replace the generic_file_aio_write, which do some write > >operations with acquiring i_data_sem lock in inode. > > > >I know that you are trying to implement extent tree, and I have seen your patch > >set '[PATCH] Rename delayed extents to status extents'. After extent tree is > >made, the implementation of direct I/O without i_mutex and range lock is > >straightforward and it is better than my trivial idea. I think that > >maybe I can borrow you works. So could you please share me your schedule > >and/or other information? > > > >Last month on ext4 workshop, we discuss the extent tree, range lock and I/O > >tree. Obviously, I/O tree is used to store I/O operations, which can track > >delay allocation, do unwritten->written conversion and implement range lock. > >It is very useful for ext4 and I am interested in this proposal. I know that > >you have begun to do some works. So would you like to tell me the status of > >extent tree? I don't know whether or not there has some things that I can be > >involved. If you have some advices or there is something that I can help, > >please let me know. Thank you and looking forward your reply. > > > >Regards, > >Zheng > > Hi Zheng, > > Well, I can share with you what I have done so far with Yongqiang's > delayed extent tree, but since I was moved to the ganesha project, > extent locks are no longer a business priority now. I've done some > work on it on my own time, but I have not been able to keep up pace > with it. If someone else has the hours to push it faster than I can > at this point, I would certainly be understanding of that. > > Basically though the plan was to modify Yongqiang's delayed extent > tree to track allocated extents as well as delayed extents. And > then add the extent locks on top of that once that's working. My > idea was to add a type member to the extents so that we have have > "delayed" "allocated" and "hole" extents. I've renamed the delayed > extent scheme to "status extents" because it seemed more > appropriate. That part I can send out, but I was still in the > middle of coding and debugging allocated extents and extent locks. > Because the tree was originally written to merge things as much as > possible, there is some rewrite that is needed. I was working on > making the add and remove routines more like "type replace" routines > sense once the extent is locked, we can really only change the type, > and we cannot merge dissimilar types or extents locked by other > processes. I hope that makes sense, please let me know if you need > more clarification. I will send out the status extent set, sense > that part is stable. Thank you for sharing with me. I am willing to take this work because my employee provides me a full time to finish this work. I see that you have sent the patch set to the mailing list. I will pick it and go on working. Thanks again. :) Regards, Zheng -- 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
