New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: Describe mClock's use within Ceph in great detail. #16707

Merged
merged 1 commit into from Aug 1, 2017

Conversation

Projects
None yet
3 participants
@ivancich
Member

ivancich commented Jul 31, 2017

It seems many are initially unclear as to how the current
implementations of mclock op queues work, so we need to document it to
avoid confusion.

Signed-off-by: J. Eric Ivancich ivancich@redhat.com

doc: Describe mClock's use within Ceph in great detail.
It seems many are initially unclear as to how the current
implementations of mclock op queues work, so we need to document it to
avoid confusion.

Signed-off-by: J. Eric Ivancich <ivancich@redhat.com>

@ivancich ivancich requested review from tchaikov and jdurgin Jul 31, 2017

@ivancich

This comment has been minimized.

Member

ivancich commented Jul 31, 2017

jenkins retest this please

@jdurgin

jdurgin approved these changes Aug 1, 2017

Nice and extensive!

competitor "1". In the case of client ops, it is not clamped by the limit
setting, so it can make use of all the resources if there is no recovery
ongoing.
The settings above ensure that the recovery won't get more than 5

This comment has been minimized.

@tchaikov

tchaikov Aug 1, 2017

Contributor

i think the reservation will be updated with the request's cost if the request is to be served. and the cost is different from one request to another. so can we equate the unit of reservation/limit to the number of requests?

we're using a distributed system, where requests are made to multiple
OSDs and each OSD has (can have) multiple shards. Yet we're currently
using the mClock algorithm, which is not distributed (note: dmClock is
the distributed version of mClock).

This comment has been minimized.

@tchaikov

tchaikov Aug 1, 2017

Contributor

i am confused. IIUC, mClock is not distributed. but dmClock is distributed. so it should read

we're using the dmClock algorithm, which is distributed.

am i right?

This comment has been minimized.

@ivancich

ivancich Aug 1, 2017

Member

So the library implements both mClock and dmClock. dmClock requires that the clients send additional information with each request labeled rho and delta that give a measure of service the client received from other servers. That way the server receiving the request can reduce the level of service to compensate.

The integration on master does not currently send rho and delta in with requests. There is a PR from SK Telecom that adds this, though.

So w.r.t. master, it only uses mClock currently.

This comment has been minimized.

@tchaikov

tchaikov Aug 1, 2017

Contributor

got it. thanks a lot for explaining this to me in details!

@tchaikov tchaikov merged commit ffbf113 into ceph:master Aug 1, 2017

4 checks passed

Signed-off-by all commits in this PR are signed
Details
Unmodified Submodules submodules for project are unmodified
Details
make check make check succeeded
Details
make check (arm64) make check succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment