Re: io_uring failure on parisc with VIPT caches

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

 



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.

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





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux