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;
?
> 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.
Thanks,
Miklos
