On Tue, Apr 19, 2011 at 10:17:17PM +0800, Wu Fengguang wrote: > [snip] > > > > > For throttling case, apart from metadata, I found that with simple > > > > > throttling of data I ran into issues with journalling with ext4 mounuted > > > > > in ordered mode. So it was suggested that WRITE IO throttling should > > > > > not be done at device level instead try to do it in higher layers, > > > > > possibly balance_dirty_pages() and throttle process early. > > > > > > > > The problem with doing it at the page cache entry level is that > > > > cache hits then get throttled. It's not really a an IO controller at > > > > that point, and the impact on application performance could be huge > > > > (i.e. MB/s instead of GB/s). > > > > > > Agreed that throttling cache hits is not a good idea. Can we determine > > > if page being asked for is in cache or not and charge for IO accordingly. > > > > You'd need hooks in find_or_create_page(), though you have no > > context of whether a read or a write is in progress at that point. > > I'm confused. Where is the throttling at cache hits? > > The balance_dirty_pages() throttling kicks in at write() syscall and > page fault time. For example, generic_perform_write(), do_wp_page() > and __do_fault() will explicitly call > balance_dirty_pages_ratelimited() to do the write throttling. This comment was in the context of what if we move block IO controller read throttling also in higher layers. Then we don't want to throttle reads which are already in cache. Currently throttling hook is in generic_make_request() and it kicks in only if data is not present in page cache and actual disk IO is initiated. Thanks Vivek -- 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
