Re: possible selrecord optimization ?

On Wednesday, January 22, 2014 7:39:48 pm Luigi Rizzo wrote:
> On Wed, Jan 22, 2014 at 02:29:56PM -0500, John Baldwin wrote:
> > On Tuesday, January 21, 2014 9:25:27 pm Luigi Rizzo wrote:
> > > Looking at how selrecord() / selwakeup() and their Linux counterparts
> > > poll_wait() and wake_up() are used, i noticed the following:
> ....
> > > I wonder if we could use the same optimization as Linux:
> > > as soon as pollscan/selscan detects a non-blocking fd,
> > > make selrecord a no-op (which is probably as simple
> > > as setting SELTD_RESCAN; and since it only goes up
> > > we do not need to lock to check it).
> > 
> > Yes, I think this would work fine.  I think setting SELTD_RESCAN as a way to 
> > do it is fine as well.
> 
> excellent, thanks.
> 
> I also have two related questions:
> 
> 1. why isn't the struct mtx part of the struct selinfo instead
>    of being grabbed from the mtxpool_select ?

I think this is because there is no selinfo_init() and no selinfo_destroy(),
so there is no way to manage the lifetime of the mutex were it embedded into
the structure.  Also, if there are a lot of these structures, but only a
subset of them are ever accessed, then a smaller set of locks that are
hashed onto the structures may work just fine without introducing extra
contention (but with the benefit of saving space in the structures).

> 2. am i correct that we do need to protect concurrent invocations
>    of selrecord() on the same selinfo because mtx_pool_find()
>    return the same mutex for a given struct selinfo ?

If you mean 'do not need', yes.  mtx_pool_find() does a hash on the address,
so it will always return the same lock for a given selinfo, and no external
locking should be needed by callers.  However, callers often need to check
other state for which they need to hold a lock anyway.  OTOH, if, for example,
socket buffer locks were reader/writer locks, sopoll_generic() could use
read locks on the socket buffers even while calling selrecord().

> In case, any objections if i add some comments to the code
> to explain the above ?

Not from me. :)

-- 
John Baldwin