crimson/osd: bring support for client blocklisting#47637
crimson/osd: bring support for client blocklisting#47637rzarzynski merged 3 commits intoceph:mainfrom
Conversation
src/crimson/osd/pg.cc
Outdated
| void PG::check_blocklisted_watchers() | ||
| { | ||
| logger().debug("{}", __func__); | ||
| shard_services.for_each_obc([this] (ObjectContextRef obc) { |
There was a problem hiding this comment.
This is going to iterate over object contexts for other PGs as well. The PG needs a set of its own objects with live watches -- there shouldn't in general be all that many.
There was a problem hiding this comment.
How about skipping a watch on PG mismatch?
There was a problem hiding this comment.
Iterating over all live object contexts on the shard to find the very small subset with a live watcher for this pg still strikes me as inefficient and complicated.
There was a problem hiding this comment.
I see. Perhaps we could flip the loops.
There was a problem hiding this comment.
Nope, we don't have a separate registry of watchers. The main difference with the classical is it uses a per-PG (not per-shard) registry of object contexts:
void PrimaryLogPG::check_blocklisted_watchers()
{
dout(20) << "PrimaryLogPG::check_blocklisted_watchers for pg " << get_pgid() << dendl;
pair<hobject_t, ObjectContextRef> i;
while (object_contexts.get_next(i.first, &i))
check_blocklisted_obc_watchers(i.second);
}Duplicating the information looks even worse. HOWEVER:
using lru_set_t = boost::intrusive::set<
base_t,
lru_set_option_t,
boost::intrusive::key_of_value<VToKWrapped>
>;
lru_set_t lru_set;Maybe, by changing the key derivation function, we could have OBCs sorted / prefixed by PG-derived part.
There was a problem hiding this comment.
Do we really need the per-shard aggregation of OBCs?
There was a problem hiding this comment.
Probably not, tbh. We can just let each PG have its own.
f38adc7 to
845692a
Compare
845692a to
fa61dbb
Compare
fa61dbb to
a6f870f
Compare
|
jenkins retest this please |
|
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
211bbaf to
471b386
Compare
|
@athanatos: would you mind another look? |
|
Incidentally, if you re-request review it'll pop back up on my github query for PRs waiting on a review from me. |
|
Ping |
|
Looks like comments haven't been addressed? |
471b386 to
08157f7
Compare
|
The pushed revision addresses just the minors; the iteration thing requires further discussion. |
This patch moves the OBC registry from ShardServices (which is basicaly a gateway to a bunch of PGs) into PG itself. Dividing OBCs by PG (they truly belong to) minimizes the space to search when e.g. checking whether a client is blocked or not. Therefore, this commit is enabler of more performant PR ceph#47637. The changeset draws the assumption that OBC registry and all its users live on the same CPU core. It looks valid to me. Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
This patch moves the OBC registry from ShardServices (which is basicaly a gateway to a bunch of PGs) into PG itself. Dividing OBCs by PG (they truly belong to) minimizes the space to search when e.g. checking whether a client is blocked or not. Therefore, this commit is enabler of more performant PR ceph#47637. The changeset draws the assumption that OBC registry and all its users live on the same CPU core. It looks valid to me. Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
This patch moves the OBC registry from ShardServices (which is basicaly a gateway to a bunch of PGs) into PG itself. Dividing OBCs by PG (they truly belong to) minimizes the space to search when e.g. checking whether a client is blocked or not. Therefore, this commit is enabler of more performant PR ceph#47637. The changeset draws the assumption that OBC registry and all its users live on the same CPU core. It looks valid to me. Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
This patch moves the OBC registry from ShardServices (which is basicaly a gateway to a bunch of PGs) into PG itself. Dividing OBCs by PG (they truly belong to) minimizes the space to search when e.g. checking whether a client is blocked or not. Therefore, this commit is enabler of more performant PR ceph#47637. The changeset draws the assumption that OBC registry and all its users live on the same CPU core. It looks valid to me. Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
This patch moves the OBC registry from ShardServices (which is basicaly a gateway to a bunch of PGs) into PG itself. Dividing OBCs by PG (they truly belong to) minimizes the space to search when e.g. checking whether a client is blocked or not. Therefore, this commit is enabler of more performant PR ceph#47637. The changeset draws the assumption that OBC registry and all its users live on the same CPU core. It looks valid to me. Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
|
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
08157f7 to
654eadf
Compare
|
I think we're waiting on tests here. A crimson-rados suite should suffice. Normally the change in common/ would require a rados suite, but testing infrastructure is backed up and the added method has no users in classic so there isn't any real risk. |
|
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
|
@rzarzynski, Let's get this merged for |
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
`PG` directly aggregates both `OSDMap` and `PeeringState` which maintains its own `OSDMap` instance. This duplication leads to issues as the `PG::osdmap` never gets updated. Signed-off-by: Radoslaw Zarzynski <rzarzyns@redhat.com>
654eadf to
d8655c0
Compare
|
@Matan-B: rebased. Let's finish this PR! |
|
|
jenkins test make check |
|
Once make check is up again, this PR can be merged based on:
|
|
|
jenkins test make check |
1 similar comment
|
jenkins test make check |
Contribution Guidelines
To sign and title your commits, please refer to Submitting Patches to Ceph.
If you are submitting a fix for a stable branch (e.g. "pacific"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.
Checklist
Show available Jenkins commands
jenkins retest this pleasejenkins test classic perfjenkins test crimson perfjenkins test signedjenkins test make checkjenkins test make check arm64jenkins test submodulesjenkins test dashboardjenkins test dashboard cephadmjenkins test apijenkins test docsjenkins render docsjenkins test ceph-volume alljenkins test ceph-volume toxjenkins test windows