Re: [RFC PATCH 2/4] ipvs: use kthreads for stats estimation

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

 



On Wed, Sep 07, 2022 at 10:01:27PM +0300, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Mon, 5 Sep 2022, Jiri Wiesner wrote:
> 
> > On Sat, Aug 27, 2022 at 08:41:52PM +0300, Julian Anastasov wrote:
> > >  
> > > +static void est_reload_work_handler(struct work_struct *work)
> > > +{
> > > +	struct netns_ipvs *ipvs =
> > > +		container_of(work, struct netns_ipvs, est_reload_work.work);
> > > +	int genid = atomic_read(&ipvs->est_genid);
> > > +	int genid_done = atomic_read(&ipvs->est_genid_done);
> > > +	unsigned long delay = HZ / 10;	/* repeat startups after failure */
> > > +	bool repeat = false;
> > > +	int id;
> > > +
> > > +	mutex_lock(&ipvs->est_mutex);
> > > +	for (id = 0; id < ipvs->est_kt_count; id++) {
> > > +		struct ip_vs_est_kt_data *kd = ipvs->est_kt_arr[id];
> > > +
> > > +		/* netns clean up started, abort delayed work */
> > > +		if (!ipvs->enable)
> > > +			goto unlock;
> > 
> > It would save some code to move the ipvs->enable check before the critical section and use a return statement right away.
> 
> 	I preferred to react to cleanup_net() faster and
> avoid creating threads if this is what we try to do here.

I meant putting
if (!ipvs->enable)
	return;
right before the mutex_lock() statement.

-- 
Jiri Wiesner
SUSE Labs



[Index of Archives]     [Linux Filesystem Devel]     [Linux NFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]     [X.Org]

  Powered by Linux