On 2023-02-14 6:29 p.m., Jens Axboe wrote:
On 2/14/23 4:09 PM, Helge Deller wrote:
* John David Anglin<dave.anglin@xxxxxxxx>:
On 2023-02-13 5:05 p.m., Helge Deller wrote:
On 2/13/23 22:05, Jens Axboe wrote:
On 2/13/23 1:59?PM, Helge Deller wrote:
Yep sounds like it. What's the caching architecture of parisc?
parisc is Virtually Indexed, Physically Tagged (VIPT).
That's what I assumed, so virtual aliasing is what we're dealing with
here.
Thanks for the patch!
Sadly it doesn't fix the problem, as the kernel still sees
ctx->rings->sq.tail as being 0.
Interestingly it worked once (not reproduceable) directly after bootup,
which indicates that we at least look at the right address from kernel side.
So, still needs more debugging/testing.
It's not like this is untested stuff, so yeah it'll generally be
correct, it just seems that parisc is a bit odd in that the virtual
aliasing occurs between the kernel and userspace addresses too. At least
that's what it seems like.
True.
But I wonder if what needs flushing is the user side, not the kernel
side? Either that, or my patch is not flushing the right thing on the
kernel side.
The patch below seems to fix the issue.
I've successfuly tested it with the io_uring-test testcase on
physical parisc machines with 32- and 64-bit 6.1.11 kernels.
The idea is similiar on how a file is mmapped shared by two
userspace processes by keeping the lower bits of the virtual address
the same.
Cache flushes from userspace don't seem to be needed.
Are they from the kernel side, if the lower bits mean we end up
with the same coloring? Because I think this is a bit of a big
hammer, in terms of overhead for flushing. As an example, on arm64
that is perfectly fine with the existing code, it's about a 20-25%
performance hit.
The io_uring-test testcase still works on rp3440 with the kernel flushes removed.
--
John David Anglin dave.anglin@xxxxxxxx
