unified qos model

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux