I've been thinking a bit about how the three [d]mclock modes (client, pool, op type) modes can be combined. We'd talked before about a hierarchical mode of some sort. Just thinking a bit about how I'd want/expect the various reservations and limits to interact, though, I'm not sure how well that will work. For example, let's look at just the op type vs client modes. On the op front, I would expect 2 categories of work: client work and background work (scrub, recovery, snap trimming, etc.). And I would expect the background "knob" to be something like "max of 20% background work" (or rather, "reduce overall client throughput by no more than 20%"). I would also expect/want something like "reserve at least 10% for background work to make forward progress". It's not clear to me that either of those limits "fit" into the mclock model of a reservation or priority; they're a bit of a special case. Similarly, in the pool policy case, I'm struggling to imagine how that would be configured. It doesn't make sense to have a "reservation" for pools since we don't have a global view. We could have a priority relative to other pools (there'd need to be a 'default' priority for pools that don't have it set). Or, we could have a similar percentage-style reservation like the above. And these would probably be subserviant to the client reservations (i.e., come out of the leftover by-priority phase). The percentage-style configurables are tricky, though, because we (probably?) need to have a model of what 100% is in order to make them work? If we estimate the total throughput then we could model the background work as a client with a min reservation and a max, I guess... Anyway, the whole thing makes me think that we might end up a custom scheduler that is an ad hoc combination of mclock and these secondary constraints... Has anyone had any bright ideas here? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html