* Extent tree status asking @ 2012-04-16 17:55 Zheng Liu 2012-04-18 6:19 ` Allison Henderson 0 siblings, 1 reply; 4+ messages in thread From: Zheng Liu @ 2012-04-16 17:55 UTC (permalink / raw) To: Allison Henderson; +Cc: linux-ext4 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Extent tree status asking 2012-04-16 17:55 Extent tree status asking Zheng Liu @ 2012-04-18 6:19 ` Allison Henderson 2012-04-19 9:38 ` Zheng Liu 0 siblings, 1 reply; 4+ messages in thread From: Allison Henderson @ 2012-04-18 6:19 UTC (permalink / raw) To: linux-ext4 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. Allison Henderson > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Extent tree status asking 2012-04-18 6:19 ` Allison Henderson @ 2012-04-19 9:38 ` Zheng Liu 2012-04-21 0:12 ` Allison Henderson 0 siblings, 1 reply; 4+ messages in thread From: Zheng Liu @ 2012-04-19 9:38 UTC (permalink / raw) To: Allison Henderson; +Cc: linux-ext4 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Extent tree status asking 2012-04-19 9:38 ` Zheng Liu @ 2012-04-21 0:12 ` Allison Henderson 0 siblings, 0 replies; 4+ messages in thread From: Allison Henderson @ 2012-04-21 0:12 UTC (permalink / raw) To: linux-ext4 On 04/19/2012 02:38 AM, Zheng Liu wrote: > 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 > Alrighty then, thx Zheng for continuing this work item. Let me know if you have any questions or need any help. :) Allison Henderson ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-04-21 0:12 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-04-16 17:55 Extent tree status asking Zheng Liu 2012-04-18 6:19 ` Allison Henderson 2012-04-19 9:38 ` Zheng Liu 2012-04-21 0:12 ` Allison Henderson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.