Re: [PATCH 05/19] SUNRPC: use sv_lock to protect updates to sv_nrthreads.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 24 Nov 2021, Chuck Lever III wrote:
> > @@ -639,7 +639,10 @@ svc_prepare_thread(struct svc_serv *serv, struct svc_pool *pool, int node)
> > 		return ERR_PTR(-ENOMEM);
> > 
> > 	svc_get(serv);
> > -	serv->sv_nrthreads++;
> > +	spin_lock_bh(&serv->sv_lock);
> > +	serv->sv_nrthreads += 1;
> > +	spin_unlock_bh(&serv->sv_lock);
> 
> atomic_t would be somewhat lighter weight. Can it be used here
> instead?
> 

We could....  but sv_nrthreads is read-mostly.  There are 11 places
where we would need to call "atomic_read()", and just two where we
benefit from the simplicity of atomic_inc/dec.

And even if I did achieve dynamic threads count management, we would not
be changing sv_nrthreads often enough that any performance difference
would be noticeable.
So I'd rather stick with using the spinlock and keeping the read-side
simple.

Thanks,
NeilBrown




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux