From: Julien Grall <firstname.lastname@example.org> To: Jan Beulich <email@example.com>, Andrew Cooper <firstname.lastname@example.org> Cc: George Dunlap <email@example.com>, Ian Jackson <firstname.lastname@example.org>, Stefano Stabellini <email@example.com>, Wei Liu <firstname.lastname@example.org>, email@example.com, Dmitry Isaikin <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Paul Durrant <email@example.com> Subject: Re: [PATCH v1] domctl: hold domctl lock while domain is destroyed Date: Fri, 17 Sep 2021 14:27:20 +0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> Hi, (+ some AWS folks) On 17/09/2021 11:17, Jan Beulich wrote: > On 16.09.2021 19:52, Andrew Cooper wrote: >> On 16/09/2021 13:30, Jan Beulich wrote: >>> On 16.09.2021 13:10, Dmitry Isaikin wrote: >>>> From: Dmitry Isaykin <firstname.lastname@example.org> >>>> >>>> This significantly speeds up concurrent destruction of multiple domains on x86. >>> This effectively is a simplistic revert of 228ab9992ffb ("domctl: >>> improve locking during domain destruction"). There it was found to >>> actually improve things; >> >> Was it? I recall that it was simply an expectation that performance >> would be better... > > My recollection is that it was, for one of our customers. > >> Amazon previously identified 228ab9992ffb as a massive perf hit, too. > > Interesting. I don't recall any mail to that effect. Here we go: https://email@example.com/ We have been using the revert for quite a while in production and didn't notice any regression. > >> Clearly some of the reasoning behind 228ab9992ffb was flawed and/or >> incomplete, and it appears as if it wasn't necessarily a wise move in >> hindsight. > > Possible; I continue to think though that the present observation wants > properly understanding instead of more or less blindly undoing that > change. To be honest, I think this is the other way around. You wrote and merged a patch with the following justification: " There is no need to hold the global domctl lock across domain_kill() - the domain lock is fully sufficient here, and parallel cleanup after multiple domains performs quite a bit better this way. " Clearly, the original commit message is lacking details on the exact setups and numbers. But we now have two stakeholders with proof that your patch is harmful to the setup you claim perform better with your patch. To me this is enough justification to revert the original patch. Anyone against the revert, should provide clear details of why the patch should not be reverted. Cheers, -- Julien Grall
next prev parent reply other threads:[~2021-09-17 9:27 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-16 11:10 Dmitry Isaikin 2021-09-16 12:30 ` Jan Beulich 2021-09-16 13:08 ` Roger Pau Monné 2021-09-16 17:52 ` Andrew Cooper 2021-09-17 6:17 ` Jan Beulich 2021-09-17 9:27 ` Julien Grall [this message] 2021-09-17 9:41 ` Andrew Cooper 2021-09-17 9:47 ` Jan Beulich 2021-09-17 16:01 ` Julien Grall 2021-09-20 8:19 ` Jan Beulich
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v1] domctl: hold domctl lock while domain is destroyed' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.