Re: [PATCH 3/5] ipc/sem: optimize perform_atomic_semop()

[Manfred Spraul]

This is a multi-part message in MIME format.
Hi Davidlohr,

On 09/13/2016 10:33 AM, Davidlohr Bueso wrote:
> > > @@ -1751,12 +1820,17 @@ SYSCALL_DEFINE4(semtimedop, int, semid, 
> > > struct sembuf __user *, tsops,
> > >          if (sop->sem_num >= max)
> > >              max = sop->sem_num;
> > >          if (sop->sem_flg & SEM_UNDO)
> > > -            undos = 1;
> > > +            undos = true;
> > >          if (sop->sem_op != 0)
> > > -            alter = 1;
> > > +            alter = true;
> > > +        if (sop->sem_num < SEMOPM_FAST && !dupsop) {
> > > +            if (dup & (1 << sop->sem_num))
> > > +                dupsop = 1;
> > > +            else
> > > +                dup |= 1 << sop->sem_num;
> > > +        }
> > >      }
> > At least for nsops=2, sops[0].sem_num !=sops[1].sem_num can detect 
> > absense of duplicated ops regardless of the array size.
> > Should we support that?
>
> There are various individual cases like that (ie obviously nsops == 1, 
> alter == 0, etc)
> where the dup detection would be unnecessary, but it seems like a 
> stretch to go
> at it like this. The above will work on the common case (assuming 
> lower sem_num
> of course). So I'm not particularly worried about being too smart at 
> the dup detection.
What about the attached dup detection?

--
    Manfred