On Wed, Jul 11, 2007 at 04:41:03PM +0300, Mindaugas R. wrote:

> Good idea. But perhaps we should start thinking about CPU detaching too,
> and there should be some table with active/inactive CPUs.
> Would we create only a new variable in cpu_info for now?

There are also CPU partitions to consider. IMHO we're a bit far off from
that and should probably get the kernel properly multithreaded first :-).
As long as we hide the implementation from workqueue users we can go back
and change it at will later.
 
> > If you are to use an index, it probably means dynamically allocating and
> > sizing struct workqueue.
> Why entire struct workqueue, not only struct workqueue_queue? Such was my
> primary intention, but I am not sure how it should behave in CPUs detaching
> case?

- having the caller provide storage for 'struct workqueue' means any time
  its members change LKM compatibility is lost.

- to support an arbitrary number of cpus you need an index or variable
  sized allocation, so making struct workqueue statically sized could be
  wasteful, if that is something we do.

- if you have to allocate multiple workqueue_queues and you want to ensure
  alignment for cache reasons, there will be slop (wasted memory). if it's
  all together as one block there's likely to be less waste than when using
  multiple allocations, one for each worqueue_queue.

Thanks,
Andrew