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