Re: [Lse-tech] [PATCH] new bitmap list format (for cpusets)

[Dinakar Guniguntala <dino@in.ibm.com>]

On Wed, Aug 11, 2004 at 09:17:32AM -0700, Paul Jackson wrote:
> Dinakar wrote:
> > Considering that cpu_possible_map does not get fully initialized
> > until smp_prepare_cpus gets called by init(), I thought it right
> > to move cpuset_init() to after smp initialization.
> 
> Thank-you.  I suspect you're right.
> 
> Could you also provide some motivation for the other changes in your
> patch, moving struct cpuset, enum cpuset_flagbits_t, and struct cpuset
> top_cpuset definitions from kernel/cpuset.c to include/linux/cpuset.h?
> I had found it rather pleasing that these structures did not need to
> be known outside of kernel/cpuset.c.

Since init() is executed by a kernel_thread that does a do_fork(),
it already expects the top_cpuset to be initialized. Since this can
be achieved by initializing the task structure (INIT_TASK), I had
to move the structure definitions to the header file.

A related Q, I was wondering why the nodemask_t needed to be part 
of the task_struct, since cpuset would anyway have a reference to it. 
Sorry if this is something very obvious, I didn't really look to see 
why it was there

> 
> Another approach that might work, in order to ensure that the top_cpuset
> has its cpus_allowed set to the proper value of cpu_possible_map, would
> be to add a routine, say cpuset_init_smp(), called from init/main.c
> init() just after smp_init() returns, to update the cpus_allowed in
> top_cpuset from the fully initialized value of cpu_possible_map.  This
> seems to resemble the call sched_init_smp(), also made in init/main.c
> init() just after smp_init() returns, to finish initializing some sched
> stuff.

Yes that would be fine too.

> 
> If you take your approach, should we remove the __init qualifier from
> kernel/cpuset.c cpuset_init()?
> 
The qualifier would still be valid I think, no ?

Regards,

Dinakar