On 4/3/25 14:15, Miklos Szeredi wrote:
> On Thu, 3 Apr 2025 at 11:16, Bernd Schubert <bernd@xxxxxxxxxxx> wrote:
>>
>> Hi Miklos,
>>
>> thanks for the quick reply.
>>
>> On 4/2/25 20:29, Miklos Szeredi wrote:
>>> On Wed, 2 Apr 2025 at 19:41, Bernd Schubert <bschubert@xxxxxxx> wrote:
>>>>
>>>> No need to take lock, we can have that in atomic way.
>>>> fuse-io-uring and virtiofs especially benefit from it
>>>> as they don't need the fiq lock at all.
>>>
>>> This is good.
>>>
>>> It would be even better to have per-cpu counters, each initialized to
>>> a cpuid * FUSE_REQ_ID_STEP and jumping by NR_CPU * FUSE_REQ_ID_STEP.
>>>
>>> Hmm?
>>
>> /**
>> * Get the next unique ID for a request
>> */
>> static inline u64 fuse_get_unique(struct fuse_iqueue *fiq)
>> {
>> int step = FUSE_REQ_ID_STEP * (task_cpu(current) + 1);
>> u64 cntr = this_cpu_inc_return(*fiq->reqctr);
>>
>> return cntr * step;
>
> return cntr * FUSE_REQ_ID_STEP * NR_CPU + step;
Thanks, updated.
>
> ?
>
>> Slight issue is that request IDs now have quite an up down,
>> even more than patch 2/4. Ok with you?
>
> Being more obvious is an advantage, since any issues will come to light sooner.
I sent v2, non linear values between cores should be an issue we could
feel free to back to v1.
Thanks,
Bernd
