| Message ID | 20240930195837.825728-1-peterx@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | migration: query-migrationthreads enhancements and cleanups | expand |
Command query-migrationthreads went in without a QAPI ACK. Issues review should have caught: * Flawed documentation. Fixed in commit e6c60bf02d1. * It should have been spelled query-migration-threads. Not worth fixing now, I guess. * What are the use cases? The commit message doesn't tell! If it's just for debugging, the command should be marked unstable.
On Tue, Oct 01, 2024 at 07:46:09AM +0200, Markus Armbruster wrote: > Command query-migrationthreads went in without a QAPI ACK. Issues > review should have caught: > > * Flawed documentation. Fixed in commit e6c60bf02d1. > > * It should have been spelled query-migration-threads. Not worth fixing > now, I guess. > > * What are the use cases? The commit message doesn't tell! If it's > just for debugging, the command should be marked unstable. It is hard to use too. Lets say a mgmt app wants to restrict migration threads to some certain pCPUs. It can't call query-migrationthreads beforehand as the threads don't exist until migration is started. If it calls after migration is started, then there's a window where threads are running on arbitrary pCPUs that QEMU has access to. There's no synchronization point where threads have been created & can be queried, but are not yet sending data (and thus burning CPU time) With regards, Daniel
On Tue, Oct 01, 2024 at 03:25:14PM +0100, Daniel P. Berrangé wrote: > On Tue, Oct 01, 2024 at 07:46:09AM +0200, Markus Armbruster wrote: > > Command query-migrationthreads went in without a QAPI ACK. Issues > > review should have caught: > > > > * Flawed documentation. Fixed in commit e6c60bf02d1. > > > > * It should have been spelled query-migration-threads. Not worth fixing > > now, I guess. > > > > * What are the use cases? The commit message doesn't tell! If it's > > just for debugging, the command should be marked unstable. > > It is hard to use too. > > Lets say a mgmt app wants to restrict migration threads to some > certain pCPUs. It can't call query-migrationthreads beforehand > as the threads don't exist until migration is started. If it > calls after migration is started, then there's a window where > threads are running on arbitrary pCPUs that QEMU has access > to. There's no synchronization point where threads have been > created & can be queried, but are not yet sending data (and > thus burning CPU time) Indeed, I suppose tricks needed if to work with such model, e.g., mgmt needs to turn bw=0, start migration, query TIDs, then restore bw. However that still lacks at least the dest multifd threads, as currently it only reports src multifd threads TIDs. I don't see why a serious mgmt would like to pin and care only src threads, not dest threads, which can also eat as much (or even more) pCPU resources. For real debugging purpose, I actually don't see a major value out of it either, because GDB can provide all information that this API wants to provide, and only better with thread stacks if we want. Since I don't see how this can be used right, it didn't get proper QAPI reviews, and further I highly suspect whether this API is consumed by anyone at all.. in any serious way. Shall we remove this API (with/without going through the deprecation process)? I added the author Jiacheng too. Thanks,
Peter Xu <peterx@redhat.com> writes: > On Tue, Oct 01, 2024 at 03:25:14PM +0100, Daniel P. Berrangé wrote: >> On Tue, Oct 01, 2024 at 07:46:09AM +0200, Markus Armbruster wrote: >> > Command query-migrationthreads went in without a QAPI ACK. Issues >> > review should have caught: >> > >> > * Flawed documentation. Fixed in commit e6c60bf02d1. >> > >> > * It should have been spelled query-migration-threads. Not worth fixing >> > now, I guess. >> > >> > * What are the use cases? The commit message doesn't tell! If it's >> > just for debugging, the command should be marked unstable. >> >> It is hard to use too. >> >> Lets say a mgmt app wants to restrict migration threads to some >> certain pCPUs. It can't call query-migrationthreads beforehand >> as the threads don't exist until migration is started. If it >> calls after migration is started, then there's a window where >> threads are running on arbitrary pCPUs that QEMU has access >> to. There's no synchronization point where threads have been >> created & can be queried, but are not yet sending data (and >> thus burning CPU time) > > Indeed, I suppose tricks needed if to work with such model, e.g., mgmt > needs to turn bw=0, start migration, query TIDs, then restore bw. > > However that still lacks at least the dest multifd threads, as currently it > only reports src multifd threads TIDs. I don't see why a serious mgmt > would like to pin and care only src threads, not dest threads, which can > also eat as much (or even more) pCPU resources. Sounds like there's a use case for management applications querying TIDs, but query-migrationthreads falls short of serving it. > For real debugging purpose, I actually don't see a major value out of it > either, because GDB can provide all information that this API wants to > provide, and only better with thread stacks if we want. True. > Since I don't see how this can be used right, it didn't get proper QAPI > reviews, and further I highly suspect whether this API is consumed by > anyone at all.. in any serious way. Shall we remove this API (with/without > going through the deprecation process)? If we decide we want to serve the management application use case now, we should provide a suitable interface, then deprecate query-migrationthreads. If we decide not now or not at all, we can deprecate it right away. Removal without deprecation is also possible, but I doubt breaking our compatibility promise is justified. > I added the author Jiacheng too. Users of query-migrationthreads, please speak up!
On Wed, Oct 02, 2024 at 07:58:48AM +0200, Markus Armbruster wrote: > Peter Xu <peterx@redhat.com> writes: > > > On Tue, Oct 01, 2024 at 03:25:14PM +0100, Daniel P. Berrangé wrote: > >> On Tue, Oct 01, 2024 at 07:46:09AM +0200, Markus Armbruster wrote: > >> > Command query-migrationthreads went in without a QAPI ACK. Issues > >> > review should have caught: > >> > > >> > * Flawed documentation. Fixed in commit e6c60bf02d1. > >> > > >> > * It should have been spelled query-migration-threads. Not worth fixing > >> > now, I guess. > >> > > >> > * What are the use cases? The commit message doesn't tell! If it's > >> > just for debugging, the command should be marked unstable. > >> > >> It is hard to use too. > >> > >> Lets say a mgmt app wants to restrict migration threads to some > >> certain pCPUs. It can't call query-migrationthreads beforehand > >> as the threads don't exist until migration is started. If it > >> calls after migration is started, then there's a window where > >> threads are running on arbitrary pCPUs that QEMU has access > >> to. There's no synchronization point where threads have been > >> created & can be queried, but are not yet sending data (and > >> thus burning CPU time) > > > > Indeed, I suppose tricks needed if to work with such model, e.g., mgmt > > needs to turn bw=0, start migration, query TIDs, then restore bw. > > > > However that still lacks at least the dest multifd threads, as currently it > > only reports src multifd threads TIDs. I don't see why a serious mgmt > > would like to pin and care only src threads, not dest threads, which can > > also eat as much (or even more) pCPU resources. > > Sounds like there's a use case for management applications querying > TIDs, but query-migrationthreads falls short of serving it. > > > For real debugging purpose, I actually don't see a major value out of it > > either, because GDB can provide all information that this API wants to > > provide, and only better with thread stacks if we want. > > True. > > > Since I don't see how this can be used right, it didn't get proper QAPI > > reviews, and further I highly suspect whether this API is consumed by > > anyone at all.. in any serious way. Shall we remove this API (with/without > > going through the deprecation process)? > > If we decide we want to serve the management application use case now, > we should provide a suitable interface, then deprecate > query-migrationthreads. > > If we decide not now or not at all, we can deprecate it right away. > Removal without deprecation is also possible, but I doubt breaking our > compatibility promise is justified. > > > I added the author Jiacheng too. > > Users of query-migrationthreads, please speak up! I'll go ahead and remove it. The current plan is I'll skip the deprecation procedure for this one because I don't expect anyone would read the deprecation notification at all... aka, no real user I can ever think of, who only cares about source pinning not dest. I'll pick patch 2 out and send separately, which is still a cleanup without the query-migrationthreads API. We can keep the discussion going in the new patch. Thanks,