Re: [PATCH 0/5] Generic Ticket Spinlocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 22 Mar 2022 11:18:18 PDT (-0700), mail@xxxxxxxxxxx wrote:
On 16/03/2022 23:25, Palmer Dabbelt wrote:
Peter sent an RFC out about a year ago
<https://lore.kernel.org/lkml/YHbBBuVFNnI4kjj3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/>,
but after a spirited discussion it looks like we lost track of things.
IIRC there was broad consensus on this being the way to go, but there
was a lot of discussion so I wasn't sure.  Given that it's been a year,
I figured it'd be best to just send this out again formatted a bit more
explicitly as a patch.

This has had almost no testing (just a build test on RISC-V defconfig),
but I wanted to send it out largely as-is because I didn't have a SOB
from Peter on the code.  I had sent around something sort of similar in
spirit, but this looks completely re-written.  Just to play it safe I
wanted to send out almost exactly as it was posted.  I'd probably rename
this tspinlock and tspinlock_types, as the mis-match kind of makes my
eyes go funny, but I don't really care that much.  I'll also go through
the other ports and see if there's any more candidates, I seem to
remember there having been more than just OpenRISC but it's been a
while.

I'm in no big rush for this and given the complex HW dependencies I
think it's best to target it for 5.19, that'd give us a full merge
window for folks to test/benchmark it on their systems to make sure it's
OK.

Is there a specific way you have been testing/benching things, or is it
just a case of test what we ourselves care about?

I do a bunch of functional testing in QEMU (it's all in my riscv-systems-ci repo, but that's not really fit for human consumption so I don't tell folks to use it). That's pretty much useless for something like this: sure it'd find something just straight-up broken in the lock implementation, but the stuff I'm really worried about here would be poor interactions with hardware that wasn't designed/tested against this flavor of locks.

I don't currently do any regular testing on HW, but there's a handful of folks who do. If you've got HW you care about then the best bet is to give this a shot on it. There's already been some boot test reports, so it's at least mostly there (on RISC-V, last I saw it was breaking OpenRISC so there's probably some lurking issue somewhere). I was hoping we'd get enough coverage that way to have confidence in this, but if not then I've got a bunch of RISC-V hardware lying around that I can spin up to fill the gaps.

As far as what workloads, I really don't know here. At least on RISC-V, I think any lock microbenchmarks would be essentially meaningless: this is fair, so even if lock/unlock is a bit slower that's probably a win for real workloads. That said, I'm not sure any of the existing hardware runs any workloads that I'm personally interested in so unless this is some massive hit to just general system responsiveness or make/GCC then I'm probably not going to find anything.

Happy to hear if anyone has ideas, though.


Thanks,
Conor.

RISC-V has a forward progress guarantee so we should be safe, but
these can always trip things up.



[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux