Re: [PATCH v8 00/74] per-CPU locks
Robert Foley writes: > V7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00786.html > > This is a continuation of the series created by Emilio Cota. > We are picking up this patch set with the goal to apply > any fixes or updates needed to get this accepted. > > Quoting an earlier patch in the series: > "For context, the goal of this series is to substitute the BQL for the > per-CPU locks in many places, notably the execution loop in cpus.c. > This leads to better scalability for MTTCG, since CPUs don't have > to acquire a contended global lock (the BQL) every time they > stop executing code. > See the last commit for some performance numbers." Aside from some minor comments I think this series is pretty good to go and would favour an early merging so we get plenty of time to shake out any bugs. I've been hammering this with my looped build test and everything seems pretty stable. So for me have a: Tested-by: Alex Bennée for the series. -- Alex Bennée
Re: [PATCH v8 00/74] per-CPU locks
On Fri, Mar 27, 2020 at 11:59:37AM +0100, Philippe Mathieu-Daudé wrote: > On 3/27/20 6:14 AM, Emilio G. Cota wrote: > > (Apologies if I missed some Cc's; I was not Cc'ed in patch 0 > > so I'm blindly crafting a reply.) > > > > On Thu, Mar 26, 2020 at 15:30:43 -0400, Robert Foley wrote: > > > This is a continuation of the series created by Emilio Cota. > > > We are picking up this patch set with the goal to apply > > > any fixes or updates needed to get this accepted. > > > > Thanks for picking this up! > > > > > Listed below are the changes for this version of the patch, > > > aside from the merge related changes. > > > > > > Changes for V8: > > > - Fixed issue where in rr mode we could destroy the BQL twice. > > > > I remember doing little to no testing in record-replay mode, so > > there should be more bugs hiding in there :-) > > > > > - Found/fixed bug that had been hit in testing previously during > > > the last consideration of this patch. > > > We reproduced the issue hit in the qtest: bios-tables-test. > > > The issue was introduced by dropping the BQL, and found us > > > (very rarely) missing the condition variable wakeup in > > > qemu_tcg_rr_cpu_thread_fn(). > > > > Aah, this one: > >https://patchwork.kernel.org/patch/10838149/#22516931 > > How did you identify the problem? Was it code inspection or using a tool > > like rr? I remember this being hard to reproduce reliably. > > > > On a related note, I've done some work to get QEMU-system to work > > under thread sanitizer, since tsan now supports our longjmp-based > > coroutines (hurrah!). My idea was to integrate tsan in QEMU (i.e. > > bring tsan warnings to 0) before (re)trying to merge the > > per-CPU lock patchset; this would minimize the potential for > > regressions, which from my personal viewpoint seems like a reasonable > > thing to do especially now that I have little time to work on QEMU. > > > > If there's interest in doing the tsan work first, then I'd be > > happy to send to the list as soon as this weekend the changes that > > I have so far [1]. > > I'm pretty sure Marc-André is interested (and also Stefan maybe), so Cc'ing > them. Yes, please! tsan would be another good tool to have. Stefan signature.asc Description: PGP signature
Re: [PATCH v8 00/74] per-CPU locks
On Fri, 27 Mar 2020 at 01:14, Emilio G. Cota wrote: > > (Apologies if I missed some Cc's; I was not Cc'ed in patch 0 > so I'm blindly crafting a reply.) Sorry I forgot to including you in patch 0, my bad. Will be sure to include you in the future. > On Thu, Mar 26, 2020 at 15:30:43 -0400, Robert Foley wrote: > > This is a continuation of the series created by Emilio Cota. > > We are picking up this patch set with the goal to apply > > any fixes or updates needed to get this accepted. > > Thanks for picking this up! > > > Listed below are the changes for this version of the patch, > > aside from the merge related changes. > > > > Changes for V8: > > - Fixed issue where in rr mode we could destroy the BQL twice. > > I remember doing little to no testing in record-replay mode, so > there should be more bugs hiding in there :-) Thanks for the tip! We will give record-replay some extra testing to hopefully shake some things out. :) > > > - Found/fixed bug that had been hit in testing previously during > > the last consideration of this patch. > > We reproduced the issue hit in the qtest: bios-tables-test. > > The issue was introduced by dropping the BQL, and found us > > (very rarely) missing the condition variable wakeup in > > qemu_tcg_rr_cpu_thread_fn(). > > Aah, this one: > https://patchwork.kernel.org/patch/10838149/#22516931 > How did you identify the problem? Was it code inspection or using a tool > like rr? I remember this being hard to reproduce reliably. Same here, it was hard to reproduce. I did try to use rr on some shorter runs but no luck there. We ran it overnight on one of our ARM servers and it eventually reproduced after about 12 hours in a loop across all the bios-table-test(s) (no rr). Never got it to reproduce on an x86 server. It was fairly consistent too on the same ARM host, it always reproduced within 8-12 hrs or so, and we were able to reproduce it several times. Thanks & Regards, -Rob
Re: [PATCH v8 00/74] per-CPU locks
Emilio G. Cota writes: > (Apologies if I missed some Cc's; I was not Cc'ed in patch 0 > so I'm blindly crafting a reply.) > >> Changes for V8: >> - Fixed issue where in rr mode we could destroy the BQL twice. > > I remember doing little to no testing in record-replay mode, so > there should be more bugs hiding in there :-) Well we have two (very simple) rr tests in check-tcg now - so there is that ;-) > On a related note, I've done some work to get QEMU-system to work > under thread sanitizer, since tsan now supports our longjmp-based > coroutines (hurrah!). When did that go in? Will I need a new toolchain and -ltsan to make it work? > My idea was to integrate tsan in QEMU (i.e. > bring tsan warnings to 0) before (re)trying to merge the > per-CPU lock patchset; this would minimize the potential for > regressions, which from my personal viewpoint seems like a reasonable > thing to do especially now that I have little time to work on QEMU. > > If there's interest in doing the tsan work first, then I'd be > happy to send to the list as soon as this weekend the changes that > I have so far [1]. Please do - I've been cleaning up some of the other things the sanitizer has found and it certainly won't hurt to get thread sanitizer working again. -- Alex Bennée
Re: [PATCH v8 00/74] per-CPU locks
On Fri, 27 Mar 2020 at 06:24, Aleksandar Markovic wrote: > >> >> > >> >> This is a continuation of the series created by Emilio Cota. > >> >> We are picking up this patch set with the goal to apply > >> >> any fixes or updates needed to get this accepted. > >> >> > >> > > >> > Thank for this work, Robert. > >> > > >> > However, I just hope you don't intend to request integrating the series > >> > in > >> > 5.0. The right timing for such wide-influencing patch is at the begining > >> > of > >> > dev cycle, not really at the end of (5.0) cycle, IMHO. > >> > >> It's not marked for 5.0 - I don't think all patch activity on the list > >> has to stop during softfreeze. I don't think there is any danger of it > >> getting merged and early visibility has already generated useful > >> feedback and discussion. > > > > > > OK, nobody ever said we can > > Obviously, I meant here "cannot", not "can". Everbody is allowed to do any > experimentation and evaluation of the series at any time - of course. :) We do not have any particular release in mind, but we are not intending this release for sure. It is a good point though, that we probably should have mentioned this in our cover letter, given the timing in the current release cycle. We'll remember that in the future. :) We're just looking to get this out there now to get some feedback and hopefully advance the series forward to the point that it can be included in a release in the future. Thanks & Regards, -Rob > > > examine, discuss and test the series, but I remain thinking that this > > series arrives too late for considering for 5.0. > > > > Aleksandar > > > > > >> > >> -- > >> Alex Bennée
Re: [PATCH v8 00/74] per-CPU locks
On 3/27/20 6:14 AM, Emilio G. Cota wrote: (Apologies if I missed some Cc's; I was not Cc'ed in patch 0 so I'm blindly crafting a reply.) On Thu, Mar 26, 2020 at 15:30:43 -0400, Robert Foley wrote: This is a continuation of the series created by Emilio Cota. We are picking up this patch set with the goal to apply any fixes or updates needed to get this accepted. Thanks for picking this up! Listed below are the changes for this version of the patch, aside from the merge related changes. Changes for V8: - Fixed issue where in rr mode we could destroy the BQL twice. I remember doing little to no testing in record-replay mode, so there should be more bugs hiding in there :-) - Found/fixed bug that had been hit in testing previously during the last consideration of this patch. We reproduced the issue hit in the qtest: bios-tables-test. The issue was introduced by dropping the BQL, and found us (very rarely) missing the condition variable wakeup in qemu_tcg_rr_cpu_thread_fn(). Aah, this one: https://patchwork.kernel.org/patch/10838149/#22516931 How did you identify the problem? Was it code inspection or using a tool like rr? I remember this being hard to reproduce reliably. On a related note, I've done some work to get QEMU-system to work under thread sanitizer, since tsan now supports our longjmp-based coroutines (hurrah!). My idea was to integrate tsan in QEMU (i.e. bring tsan warnings to 0) before (re)trying to merge the per-CPU lock patchset; this would minimize the potential for regressions, which from my personal viewpoint seems like a reasonable thing to do especially now that I have little time to work on QEMU. If there's interest in doing the tsan work first, then I'd be happy to send to the list as soon as this weekend the changes that I have so far [1]. I'm pretty sure Marc-André is interested (and also Stefan maybe), so Cc'ing them. Thanks, Emilio [1] WIP branch: https://github.com/cota/qemu/commits/tsan
Re: [PATCH v8 00/74] per-CPU locks
11:50 Pet, 27.03.2020. Aleksandar Markovic је написао/ла: > > > > петак, 27. март 2020., Alex Bennée је написао/ла: >> >> >> Aleksandar Markovic writes: >> >> > 21:37 Čet, 26.03.2020. Robert Foley је написао/ла: >> >> >> >> V7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00786.html >> >> >> >> This is a continuation of the series created by Emilio Cota. >> >> We are picking up this patch set with the goal to apply >> >> any fixes or updates needed to get this accepted. >> >> >> > >> > Thank for this work, Robert. >> > >> > However, I just hope you don't intend to request integrating the series in >> > 5.0. The right timing for such wide-influencing patch is at the begining of >> > dev cycle, not really at the end of (5.0) cycle, IMHO. >> >> It's not marked for 5.0 - I don't think all patch activity on the list >> has to stop during softfreeze. I don't think there is any danger of it >> getting merged and early visibility has already generated useful >> feedback and discussion. > > > OK, nobody ever said we can Obviously, I meant here "cannot", not "can". Everbody is allowed to do any experimentation and evaluation of the series at any time - of course. :) > examine, discuss and test the series, but I remain thinking that this series arrives too late for considering for 5.0. > > Aleksandar > > >> >> -- >> Alex Bennée
Re: [PATCH v8 00/74] per-CPU locks
петак, 27. март 2020., Alex Bennée је написао/ла: > > Aleksandar Markovic writes: > > > 21:37 Čet, 26.03.2020. Robert Foley је > написао/ла: > >> > >> V7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00786.html > >> > >> This is a continuation of the series created by Emilio Cota. > >> We are picking up this patch set with the goal to apply > >> any fixes or updates needed to get this accepted. > >> > > > > Thank for this work, Robert. > > > > However, I just hope you don't intend to request integrating the series > in > > 5.0. The right timing for such wide-influencing patch is at the begining > of > > dev cycle, not really at the end of (5.0) cycle, IMHO. > > It's not marked for 5.0 - I don't think all patch activity on the list > has to stop during softfreeze. I don't think there is any danger of it > getting merged and early visibility has already generated useful > feedback and discussion. > OK, nobody ever said we can examine, discuss and test the series, but I remain thinking that this series arrives too late for considering for 5.0. Aleksandar > -- > Alex Bennée >
Re: [PATCH v8 00/74] per-CPU locks
Aleksandar Markovic writes: > 21:37 Čet, 26.03.2020. Robert Foley је написао/ла: >> >> V7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00786.html >> >> This is a continuation of the series created by Emilio Cota. >> We are picking up this patch set with the goal to apply >> any fixes or updates needed to get this accepted. >> > > Thank for this work, Robert. > > However, I just hope you don't intend to request integrating the series in > 5.0. The right timing for such wide-influencing patch is at the begining of > dev cycle, not really at the end of (5.0) cycle, IMHO. It's not marked for 5.0 - I don't think all patch activity on the list has to stop during softfreeze. I don't think there is any danger of it getting merged and early visibility has already generated useful feedback and discussion. -- Alex Bennée
Re: [PATCH v8 00/74] per-CPU locks
(Apologies if I missed some Cc's; I was not Cc'ed in patch 0 so I'm blindly crafting a reply.) On Thu, Mar 26, 2020 at 15:30:43 -0400, Robert Foley wrote: > This is a continuation of the series created by Emilio Cota. > We are picking up this patch set with the goal to apply > any fixes or updates needed to get this accepted. Thanks for picking this up! > Listed below are the changes for this version of the patch, > aside from the merge related changes. > > Changes for V8: > - Fixed issue where in rr mode we could destroy the BQL twice. I remember doing little to no testing in record-replay mode, so there should be more bugs hiding in there :-) > - Found/fixed bug that had been hit in testing previously during > the last consideration of this patch. > We reproduced the issue hit in the qtest: bios-tables-test. > The issue was introduced by dropping the BQL, and found us > (very rarely) missing the condition variable wakeup in > qemu_tcg_rr_cpu_thread_fn(). Aah, this one: https://patchwork.kernel.org/patch/10838149/#22516931 How did you identify the problem? Was it code inspection or using a tool like rr? I remember this being hard to reproduce reliably. On a related note, I've done some work to get QEMU-system to work under thread sanitizer, since tsan now supports our longjmp-based coroutines (hurrah!). My idea was to integrate tsan in QEMU (i.e. bring tsan warnings to 0) before (re)trying to merge the per-CPU lock patchset; this would minimize the potential for regressions, which from my personal viewpoint seems like a reasonable thing to do especially now that I have little time to work on QEMU. If there's interest in doing the tsan work first, then I'd be happy to send to the list as soon as this weekend the changes that I have so far [1]. Thanks, Emilio [1] WIP branch: https://github.com/cota/qemu/commits/tsan
Re: [PATCH v8 00/74] per-CPU locks
21:37 Čet, 26.03.2020. Robert Foley је написао/ла: > > V7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00786.html > > This is a continuation of the series created by Emilio Cota. > We are picking up this patch set with the goal to apply > any fixes or updates needed to get this accepted. > Thank for this work, Robert. However, I just hope you don't intend to request integrating the series in 5.0. The right timing for such wide-influencing patch is at the begining of dev cycle, not really at the end of (5.0) cycle, IMHO. Yours, Aleksandar > Quoting an earlier patch in the series: > "For context, the goal of this series is to substitute the BQL for the > per-CPU locks in many places, notably the execution loop in cpus.c. > This leads to better scalability for MTTCG, since CPUs don't have > to acquire a contended global lock (the BQL) every time they > stop executing code. > See the last commit for some performance numbers." > > Listed below are the changes for this version of the patch, > aside from the merge related changes. > > Changes for V8: > - Fixed issue where in rr mode we could destroy the BQL twice. > Added new function cpu_mutex_destroy(). > - Removed g_assert(qemu_mutex_iothread_locked()) > from qemu_tcg_rr_all_cpu_threads_idle(). There is an existing > case where we call qemu_tcg_rr_all_cpu_threads_idle() without > the BQL held, so we cannot assert on the lock here. > - Found/fixed bug that had been hit in testing previously during > the last consideration of this patch. > We reproduced the issue hit in the qtest: bios-tables-test. > The issue was introduced by dropping the BQL, and found us > (very rarely) missing the condition variable wakeup in > qemu_tcg_rr_cpu_thread_fn(). > - ppc: convert to cpu_halted > - Converted new code for cpu_halted and cpu_halted_set. > - hw/semihosting: convert to cpu_halted_set > - Added this patch as this code was new and needed converting. > - ppc/translate_init.inc.c > - Translated some new code here to use cpu_has_work_with_iothread_lock. > - ppc/sapr_hcall.c Translated new code to cpu_halted > - i386/hax-all.c - converted new code to cpu_interrupt_request and cpu_halted > - mips/kvm.c - converted new code to cpu_halted > - Some changes were related to files that moved, cpu.c and cpu.h > moved to hw/core/, and some changes needed to be put > there manually during the merge. > > Emilio G. Cota (69): > cpu: convert queued work to a QSIMPLEQ > cpu: rename cpu->work_mutex to cpu->lock > cpu: introduce cpu_mutex_lock/unlock > cpu: make qemu_work_cond per-cpu > cpu: move run_on_cpu to cpus-common > cpu: introduce process_queued_cpu_work_locked > cpu: make per-CPU locks an alias of the BQL in TCG rr mode > tcg-runtime: define helper_cpu_halted_set > ppc: convert to helper_cpu_halted_set > cris: convert to helper_cpu_halted_set > hppa: convert to helper_cpu_halted_set > m68k: convert to helper_cpu_halted_set > alpha: convert to helper_cpu_halted_set > microblaze: convert to helper_cpu_halted_set > cpu: define cpu_halted helpers > tcg-runtime: convert to cpu_halted_set > arm: convert to cpu_halted > ppc: convert to cpu_halted > sh4: convert to cpu_halted > i386: convert to cpu_halted > lm32: convert to cpu_halted > m68k: convert to cpu_halted > mips: convert to cpu_halted > riscv: convert to cpu_halted > s390x: convert to cpu_halted > sparc: convert to cpu_halted > xtensa: convert to cpu_halted > gdbstub: convert to cpu_halted > openrisc: convert to cpu_halted > cpu-exec: convert to cpu_halted > cpu: convert to cpu_halted > cpu: define cpu_interrupt_request helpers > exec: use cpu_reset_interrupt > arm: convert to cpu_interrupt_request > i386: convert to cpu_interrupt_request > i386/kvm: convert to cpu_interrupt_request > i386/hax-all: convert to cpu_interrupt_request > i386/whpx-all: convert to cpu_interrupt_request > i386/hvf: convert to cpu_request_interrupt > ppc: convert to cpu_interrupt_request > sh4: convert to cpu_interrupt_request > cris: convert to cpu_interrupt_request > hppa: convert to cpu_interrupt_request > lm32: convert to cpu_interrupt_request > m68k: convert to cpu_interrupt_request > mips: convert to cpu_interrupt_request > nios: convert to cpu_interrupt_request > s390x: convert to cpu_interrupt_request > alpha: convert to cpu_interrupt_request > moxie: convert to cpu_interrupt_request > sparc: convert to cpu_interrupt_request > openrisc: convert to cpu_interrupt_request > unicore32: convert to cpu_interrupt_request > microblaze: convert to cpu_interrupt_request > accel/tcg: convert to cpu_interrupt_request > cpu: convert to interrupt_request > cpu: call .cpu_has_work with the CPU lock held > cpu: introduce cpu_has_work_with_iothread_lock > ppc: convert to cpu_has_work_with_iothread_lock > mips: convert to cpu_has_work_with_iothread_lock > s390x: convert to cpu_has_work_with_iothrea
[PATCH v8 00/74] per-CPU locks
V7: https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg00786.html This is a continuation of the series created by Emilio Cota. We are picking up this patch set with the goal to apply any fixes or updates needed to get this accepted. Quoting an earlier patch in the series: "For context, the goal of this series is to substitute the BQL for the per-CPU locks in many places, notably the execution loop in cpus.c. This leads to better scalability for MTTCG, since CPUs don't have to acquire a contended global lock (the BQL) every time they stop executing code. See the last commit for some performance numbers." Listed below are the changes for this version of the patch, aside from the merge related changes. Changes for V8: - Fixed issue where in rr mode we could destroy the BQL twice. Added new function cpu_mutex_destroy(). - Removed g_assert(qemu_mutex_iothread_locked()) from qemu_tcg_rr_all_cpu_threads_idle(). There is an existing case where we call qemu_tcg_rr_all_cpu_threads_idle() without the BQL held, so we cannot assert on the lock here. - Found/fixed bug that had been hit in testing previously during the last consideration of this patch. We reproduced the issue hit in the qtest: bios-tables-test. The issue was introduced by dropping the BQL, and found us (very rarely) missing the condition variable wakeup in qemu_tcg_rr_cpu_thread_fn(). - ppc: convert to cpu_halted - Converted new code for cpu_halted and cpu_halted_set. - hw/semihosting: convert to cpu_halted_set - Added this patch as this code was new and needed converting. - ppc/translate_init.inc.c - Translated some new code here to use cpu_has_work_with_iothread_lock. - ppc/sapr_hcall.c Translated new code to cpu_halted - i386/hax-all.c - converted new code to cpu_interrupt_request and cpu_halted - mips/kvm.c - converted new code to cpu_halted - Some changes were related to files that moved, cpu.c and cpu.h moved to hw/core/, and some changes needed to be put there manually during the merge. Emilio G. Cota (69): cpu: convert queued work to a QSIMPLEQ cpu: rename cpu->work_mutex to cpu->lock cpu: introduce cpu_mutex_lock/unlock cpu: make qemu_work_cond per-cpu cpu: move run_on_cpu to cpus-common cpu: introduce process_queued_cpu_work_locked cpu: make per-CPU locks an alias of the BQL in TCG rr mode tcg-runtime: define helper_cpu_halted_set ppc: convert to helper_cpu_halted_set cris: convert to helper_cpu_halted_set hppa: convert to helper_cpu_halted_set m68k: convert to helper_cpu_halted_set alpha: convert to helper_cpu_halted_set microblaze: convert to helper_cpu_halted_set cpu: define cpu_halted helpers tcg-runtime: convert to cpu_halted_set arm: convert to cpu_halted ppc: convert to cpu_halted sh4: convert to cpu_halted i386: convert to cpu_halted lm32: convert to cpu_halted m68k: convert to cpu_halted mips: convert to cpu_halted riscv: convert to cpu_halted s390x: convert to cpu_halted sparc: convert to cpu_halted xtensa: convert to cpu_halted gdbstub: convert to cpu_halted openrisc: convert to cpu_halted cpu-exec: convert to cpu_halted cpu: convert to cpu_halted cpu: define cpu_interrupt_request helpers exec: use cpu_reset_interrupt arm: convert to cpu_interrupt_request i386: convert to cpu_interrupt_request i386/kvm: convert to cpu_interrupt_request i386/hax-all: convert to cpu_interrupt_request i386/whpx-all: convert to cpu_interrupt_request i386/hvf: convert to cpu_request_interrupt ppc: convert to cpu_interrupt_request sh4: convert to cpu_interrupt_request cris: convert to cpu_interrupt_request hppa: convert to cpu_interrupt_request lm32: convert to cpu_interrupt_request m68k: convert to cpu_interrupt_request mips: convert to cpu_interrupt_request nios: convert to cpu_interrupt_request s390x: convert to cpu_interrupt_request alpha: convert to cpu_interrupt_request moxie: convert to cpu_interrupt_request sparc: convert to cpu_interrupt_request openrisc: convert to cpu_interrupt_request unicore32: convert to cpu_interrupt_request microblaze: convert to cpu_interrupt_request accel/tcg: convert to cpu_interrupt_request cpu: convert to interrupt_request cpu: call .cpu_has_work with the CPU lock held cpu: introduce cpu_has_work_with_iothread_lock ppc: convert to cpu_has_work_with_iothread_lock mips: convert to cpu_has_work_with_iothread_lock s390x: convert to cpu_has_work_with_iothread_lock riscv: convert to cpu_has_work_with_iothread_lock sparc: convert to cpu_has_work_with_iothread_lock xtensa: convert to cpu_has_work_with_iothread_lock cpu: rename all_cpu_threads_idle to qemu_tcg_rr_all_cpu_threads_idle cpu: protect CPU state with cpu->lock instead of the BQL cpus-common: release BQL earlier in run_on_cpu cpu: add async_run_on_cpu_no_bql cputlb: queue async flush jobs without the BQL Paolo Bonzini (4): ppc: use cpu_reset_interrupt i386: use cpu_reset_interrupt s