On Tue 12-04-16 19:49:45, Jens Axboe wrote: > On 04/12/2016 06:08 PM, Dave Chinner wrote: > >On Tue, Apr 12, 2016 at 12:43:50PM -0600, Jens Axboe wrote: > >>Hi, > >> > >>Three top level patches out of the writeback throttling patchset, that > >>I think should make it into mainline. No functional changes in the > >>first two patches, and the last patch just bumps reclaim/sync > >>writeback to use WRITE_SYNC as a hint to the block layer. > > > >Whatever happened to adding a new flag to indicate that write > >requests can be throttled, rather than overloading WRITE_SYNC with > >yet another (conflicting) meaning? > > WRITE_SYNC means someone will be waiting for it. This just extends it to > cover more instances where that is the case (reclaim, for_sync). Well, the question really is how soon waiting for the write is warranting WRITE_SYNC? Someone waits (or will likely soon wait) for background writeback if we are close to dirty limit after all. Do we want WRITE_SYNC set also in that case? In your patch 3, you change the logic to issue WRITE_SYNC writes when for_reclaim or for_sync are set and these are IMHO questionable as well - for_reclaim just means that there are dirty pages near the end of LRU and thus MM blindly issues writeback requests and hopes things will improve. for_sync means we are doing the first pass of writeback for sync(2). In either of these cases I'm not sure prioritizing writes is a clear win for the system overall, although in both cases it makes some sense. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
