From: Jens Axboe <[email protected]>
To: Helge Deller <[email protected]>,
[email protected], [email protected],
John David Anglin <[email protected]>,
James Bottomley <[email protected]>
Subject: Re: io_uring failure on parisc with VIPT caches
Date: Tue, 14 Feb 2023 16:29:15 -0700 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <Y+wUwVxeN87gqN6o@p100>
On 2/14/23 4:09 PM, Helge Deller wrote:
> * John David Anglin <[email protected]>:
>> 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.
Other little complaints too in terms of which pages to flush, eg
it's only the first page that is flushed but the ring may be
larger than that. But those are mostly moot if we can just guarantee
the lowest bits fixes the aliasing.
--
Jens Axboe
next prev parent reply other threads:[~2023-02-14 23:29 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-12 9:47 io_uring failure on parisc (32-bit userspace and 64-bit kernel) Helge Deller
2023-02-12 13:16 ` Jens Axboe
2023-02-12 13:28 ` Helge Deller
2023-02-12 13:35 ` Jens Axboe
2023-02-12 14:00 ` Jens Axboe
2023-02-12 14:03 ` Helge Deller
2023-02-12 19:35 ` Helge Deller
2023-02-12 19:42 ` Jens Axboe
2023-02-12 20:01 ` Helge Deller
2023-02-12 21:48 ` Jens Axboe
2023-02-12 22:20 ` Helge Deller
2023-02-12 22:31 ` Helge Deller
2023-02-13 16:15 ` Jens Axboe
2023-02-13 20:59 ` Helge Deller
2023-02-13 21:05 ` Jens Axboe
2023-02-13 22:05 ` Helge Deller
2023-02-13 22:50 ` John David Anglin
2023-02-14 23:09 ` io_uring failure on parisc with VIPT caches Helge Deller
2023-02-14 23:29 ` Jens Axboe [this message]
2023-02-15 2:12 ` John David Anglin
2023-02-15 15:16 ` Jens Axboe
2023-02-15 15:52 ` Helge Deller
2023-02-15 15:56 ` Jens Axboe
2023-02-15 16:02 ` Helge Deller
2023-02-15 16:04 ` Jens Axboe
2023-02-15 21:40 ` Helge Deller
2023-02-15 23:04 ` Jens Axboe
2023-02-15 16:38 ` John David Anglin
2023-02-15 17:01 ` Jens Axboe
2023-02-15 19:00 ` Jens Axboe
2023-02-15 19:16 ` Jens Axboe
2023-02-15 20:27 ` John David Anglin
2023-02-15 20:37 ` Jens Axboe
2023-02-15 21:06 ` John David Anglin
2023-02-15 21:38 ` Jens Axboe
2023-02-15 21:39 ` John David Anglin
2023-02-15 22:10 ` John David Anglin
2023-02-15 23:02 ` Jens Axboe
2023-02-15 23:43 ` John David Anglin
2023-02-16 2:40 ` John David Anglin
2023-02-16 2:50 ` Jens Axboe
2023-02-16 8:24 ` Helge Deller
2023-02-16 15:22 ` Jens Axboe
2023-02-16 20:35 ` John David Anglin
2023-02-15 23:03 ` Jens Axboe
2023-02-15 19:20 ` John David Anglin
2023-02-15 19:24 ` Jens Axboe
2023-02-15 16:18 ` John David Anglin
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox