+ dev@ceph.io On Tue, Jun 29, 2021 at 5:19 PM liucx changxi <liucxer@gmail.com> wrote:
dear kchai:
hi Changxi,
I am a new developer of ceph, and I am developing qos related content recently，Can you help me? dmclock implements qos by controlling the priority of the queue。
this is not accurate. in addition to "priority", i.e. weight or proportion, there are two other parameters in this picture -- reservation and limit. each client is configured with its own weight, reservation and limit. that's why "mClock" is prefixed with "m" (multiple), i think, as there are multiple clocks driven by these 3 parameters.
The read op is awaited synchronously. BlueStore::_do_read() { .... bdev->aio_submit(&ioc); dout(20) << __func__ << " waiting for aio" << dendl; ioc.aio_wait(); .... } But write io is performed asynchronously. How does dmclock achieve qos when writing io?
currently, we are only using mClock for QoS in OSD. its distributed variant, dmClock is not used yet at the time of writing. also, we don't do QoS in BlueStore. instead, it's implemented in the pipeline at a higher level. you might want to take a look at how OSDShard and mClockScheduler interact. basically, they prioritize requests based on the predefined profile [0] and settings, so that the ones which need higher QoS have a better chance of being executed sooner. please note, the requests being scheduled by OSDShard's scheduler include not only I/O requests, but also requests like pg peering requests. HTH --- [0] https://ceph.io/community/qos-study-with-mclock-and-wpq-schedulers/ [1] https://docs.ceph.com/en/latest/rados/configuration/mclock-config-ref/
--- liucxer