On Tue, 2009-09-08 at 13:57 -0400, Chris Mason wrote: > Going back to the streaming writer case, pretend the FS just created a > nice fat 256MB extent out of dealloc pages, but after we wrote the first > 4k, we dropped below the dirty threshold and IO is no longer "required". > > It would be silly to just write 4k. We know we have a contiguous > area 256MB long on disk and 256MB of dirty pages. In this case, pdflush > (or Jens' bdi threads) want to write some large portion of that 256MB. > > You might argue a balance_dirty_pages callers wants to return quickly, > but even then we'd want to write at least 128k. Sure and that's no problem at all,.. I'm thinking something like a fraction of the dirty limit, maybe something like (dirty_ratio-background_ratio) / 4 as chunk size. That gives a sizable amount and scales with the writeback cache stuff. Esp if we move all write activity into the bdi threads and have the application tasks wait. In that case we can release the app tasks to generate more dirty pages while still writing out data in a linear fashion. -- 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
