Hello, On Wed, May 29, 2019 at 10:27:36AM +0800, Xuehan Xu wrote: > I think, since we are offering users an interface to control the io > reqs issuing rate, we'd better provide the interface through the io > controller, is this right? I'm not entirely sure what the right approach is here. For most controllers, there are concrete resources which are being controlled even if it's a virtual resource like pids. Here, it isn't clear how the resource should be defined. Ideally, it should be defined as fractions / weights of whatever backends can do but that might not be that easy to define. Another issue is that non-work-conserving limits usually aren't enough to serve majority of use cases and it's better to at least consider how work-conserving control should look like before settling interface decisions. > Actually, for now, we are considering implement a ceph-specific > "blkcg_policy" which adds new io controller "cf" files to let users > modify configurations of the ceph-specific "blkcg_policy" and limit > the ceph reqs sent to the underlying cluster all by itself rather than > relying on the existing blkcg_policies like io latency or io throttle. > Is this the right way to go? Thanks:-) Can we take a step back and think through what the fundamental resources are? Do these control knobs even belong to the client machines? Thanks. -- tejun
