Subject: Re: workqueue(9), per-CPU queues (part 2)
To: None <ad@netbsd.org, yamt@netbsd.org>
From: Mindaugas R. <rmind@NetBSD.org>
List: tech-kern
Date: 07/25/2007 22:42:51
yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
> > Currently, WQ_PERCPU flag could be used only after all secondary CPUs
> > starts.
> 
> how about having a patchable variable max_cpu_seqid?

I am not sure what would you want to achieve with patching.
Can you explain more?

> - why name the kthread with curcpu's id in the case of ci==NULL?
> 

Changed to 0. But LWP might migrate..

> - i personally prefer more descrictive names.
>  eg. cpu_seqid(ci), CACHE_LINE_SIZE

Do you want to have an inline function?
#define	ci_seqid		ci_data.cpu_seqid
Are these names OK?

> - why u_int rather than cpuid_t?
> 

Changed to cpuid_t. This should not be confused with MD cpuid.

> - is wq_size necessary?  can't it be just recalculated?
> 

Yes, it can be recalculated. But I would like to get settled:
  a) we do not care about ncpu changes (attaching/dettaching)
  b) we might start preparing for this, eg. save ncpu (or wq_size) value
So just take a) for now?

> - q_ci doesn't seem necessary.
> 

Removed.

> - how about:
> 	#if defined(MULTIPROCESSOR)
> 	#define	WQ_CACHE_LINE_SIZE	CACHE_LINE_SIZE
> 	#else /* defined(MULTIPROCESSOR) */
> 	#define	WQ_CACHE_LINE_SIZE	(ALIGNBYTES + 1)
> 	#endif /* defined(MULTIPROCESSOR) */

Reasonable. I guess there could be more such usage in the feature - perhaps
it would be reasonable to invent some global constant?

Any objections to move CACHE_LINE_SIZE to cpu.h?

-- 
Best regards,
Mindaugas
www.NetBSD.org