No subject

"@max_active determines the maximum number of execution contexts per
CPU which can be assigned to the work items of a wq.  For example,
with @max_active of 16, at most 16 work items of the wq can be
executing at the same time per CPU."

Which means it does scale with machine size already. Essentially, we
have a maximum of 3 work concurrent work items executing on the
syncd work queue per filesystem, so I don't think there'll be any
shortage of worker contexts on a typical system....


> > @@ -535,27 +511,12 @@ xfssyncd(
> >  			break;
> >  
> >  		spin_lock(&mp->m_sync_lock);
> > -		/*
> > -		 * We can get woken by laptop mode, to do a sync -
> > -		 * that's the (only!) case where the list would be
> > -		 * empty with time remaining.
> > -		 */
> > -		if (!timeleft || list_empty(&mp->m_sync_list)) {
> > -			if (!timeleft)
> > -				timeleft = xfs_syncd_centisecs *
> > -							msecs_to_jiffies(10);
> > -			INIT_LIST_HEAD(&mp->m_sync_work.w_list);
> > -			list_add_tail(&mp->m_sync_work.w_list,
> > -					&mp->m_sync_list);
> > -		}
> 
> Does timeleft have to be re-initialized in here somewhere?
> It looks to me like it will become zero pretty quickly and
> stay there.

Yeah, you're right, though the code is completely removed in the
next patch so it's not noticable. I'll just set it unconditionally
so that bisects don't do strange things if they land on this commit.

Cheers,

Dave.

-- 
Dave Chinner
david at fromorbit.com