On 5/30/24 5:00 PM, Miklos Szeredi wrote:
> On Thu, 30 May 2024 at 05:20, Jingbo Xu wrote:
>
>>> + if (test_bit(FR_FINISHED, >flags)) {
>>> + list_del_init(>intr_entry);
>>> + spin_unlock(>lock
On 5/29/24 11:52 PM, Miklos Szeredi wrote:
> Virtiofs has its own queing mechanism, but still requests are first queued
> on fiq->pending to be immediately dequeued and queued onto the virtio
> queue.
>
> The queuing on fiq->pending is unnecessary and might even have some
> performance impact
On 5/28/24 10:21 PM, Peter-Jan Gootzen wrote:
> On Tue, 2024-05-28 at 21:35 +0800, Jingbo Xu wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 5/28/24 7:59 PM, Miklos Szeredi wrote:
>>> On Tue, 28 May 2024 at 10:52, Jingbo X
On 5/28/24 7:59 PM, Miklos Szeredi wrote:
> On Tue, 28 May 2024 at 10:52, Jingbo Xu wrote:
>>
>> Hi Peter-Jan,
>>
>> Thanks for the amazing work.
>>
>> I'd just like to know if you have any plan of making fiq and fiq->lock
>> more scalable, e.
On 5/28/24 5:05 PM, Peter-Jan Gootzen wrote:
> Hi Jingbo,
>
> On Tue, 2024-05-28 at 16:40 +0800, Jingbo Xu wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> Hi Peter-Jan,
>>
>> Thanks for the amazing work! Glad to see
Hi Peter-Jan,
Thanks for the amazing work.
I'd just like to know if you have any plan of making fiq and fiq->lock
more scalable, e.g. make fiq a per-CPU software queue? I think the
global fiq and fiq->lock can be a performance bottleneck after we have
supported mq.
--
Thanks,
Jingbo
Hi Peter-Jan,
Thanks for the amazing work! Glad to see it is upstreamed. We are also
planning distribute virtiofs on DPU.
BTW I have some questions when reading the patch, appreciate if you
could give a hint.
On 5/1/24 11:38 PM, Peter-Jan Gootzen wrote:
> Virtio-fs devices might allocate
