On Wed, Apr 20, 2011 at 02:44:33PM -0400, Vivek Goyal wrote: > On Wed, Apr 20, 2011 at 09:16:38AM +0800, Wu Fengguang wrote: > > On Wed, Apr 20, 2011 at 01:05:43AM +0800, Vivek Goyal wrote: > > > So this will be called for even meta data READS. Then there is no > > > advantage of moving the throttle hook out of generic_make_request()? > > > Instead what I will need is that ask file systems to mark meta data > > > IO so that I can avoid throttling. > > > > Do you want to avoid meta data itself, or to avoid overall performance > > being impacted as a result of meta data read throttling? > > I wanted to avoid throttling metadata beacause it might lead to reduced > overall performance due to dependencies in file system layer. > > > > > Either way, you have the freedom to test whether the passed filp is a > > normal file or a directory "file", and do conditional throttling. > > Ok, will look into it. That will probably take care of READS. What > about WRITES and meta data. Is it safe to assume that any meta data > write will come in some jounalling thread context and not in user > process context? No. Journal writes in XFS come from the context that forces them to occur, whether it be user, bdi-flusher or background kernel thread context. Indeed, we can even have journal writes coming from workqueues and there is a possibility that they will always come from a workqueue context in the next release or so. As for metadata buffer writes themselves, they currently come from background kernel threads or workqueues in most normal operational cases. However, in certain situations (e.g. sync(1), filesystem freeze and unmount) we can issue write IO on metadata buffers directly from the user process context.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
