On Thu, 2014-01-02 at 11:01 -0500, tj@xxxxxxxxxx wrote: > On Thu, Jan 02, 2014 at 03:21:15PM +0000, Chris Mason wrote: > > But there are a limited number of non-pagecache methods to do IO. Why > > not just push the accounting and throttling for O_DIRECT into a new BDI > > controller idea? Tejun was just telling me how he'd rather fix the > > existing controllers than add a new one, but I think we can have a much > > better admin experience by having a having a single entry point based on > > BDIs. > > But if we'll have to make bdis blkcg-aware, I think the better way to > do is splitting it per cgroup. That's what's being don in the lower > layer anyway. We split request queues to multiple queues according to > cgroup configuration. Things which can affect request issue and > completion, such as request allocation, are also split and each such > split queue is used for resource provisioning. This seems like the better way to me as well: per-bdi cgroups queues mirrors fairly exactly the work we had to do in the zones for kernel memory management. > What we're missing is a way to make such split visible in the upper > layers for writeback. It seems rather clear to me that that's the > right way to approach the problem rather than implementing separate > control for writebacks and somehow coordinate that with the rest. Well, you know, since bdis are block device tied, there's a natural question if this can be a similar (or identical) control plane to the one Oren is proposing for the device namespace. I know you've never really liked the idea, but this is pushing us down that path. Perhaps what we should do is a half day on cgroups before the main LSF (so in collab summit time, or just in the pub the night before) ... I'm not sure all our audience are cgroup aware ... James -- 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
