sched: 64-bit nr_running

sched: 64-bit nr_running

[Daniel Walker]

There was a conversation over the mtd redboot bug related to unsigned
long vs. unsigned int . On a 64-bit machine unsigned long is 64-bits ,
and unsigned int is 32-bits . However, both are 32-bits on a 32-bit
machine .

Looking over the scheduler I found a few places that use "unsigned long"
for task counting variables (nr_running, nr_active, nr_interruptible) .
The problem is that these variables are all bound to 29 bits (according
to kernel/pid.c) , but they get expanded to 64-bits on 64-bit machines .

I CC'd Steve cause he seems interested in the topic of variable size
issues (bitmaps , unsigned long longs , etc ) .

Daniel

Re: sched: 64-bit nr_running

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> There was a conversation over the mtd redboot bug related to unsigned 
> long vs. unsigned int . On a 64-bit machine unsigned long is 64-bits , 
> and unsigned int is 32-bits . However, both are 32-bits on a 32-bit 
> machine .
> 
> Looking over the scheduler I found a few places that use "unsigned 
> long" for task counting variables (nr_running, nr_active, 
> nr_interruptible) . The problem is that these variables are all bound 
> to 29 bits (according to kernel/pid.c) , but they get expanded to 
> 64-bits on 64-bit machines .

your point being?

	Ingo

Re: sched: 64-bit nr_running

[Daniel Walker]

On Mon, 2006-05-15 at 18:25 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > There was a conversation over the mtd redboot bug related to unsigned 
> > long vs. unsigned int . On a 64-bit machine unsigned long is 64-bits , 
> > and unsigned int is 32-bits . However, both are 32-bits on a 32-bit 
> > machine .
> > 
> > Looking over the scheduler I found a few places that use "unsigned 
> > long" for task counting variables (nr_running, nr_active, 
> > nr_interruptible) . The problem is that these variables are all bound 
> > to 29 bits (according to kernel/pid.c) , but they get expanded to 
> > 64-bits on 64-bit machines .
> 
> your point being?


We could make them unsigned int, and save the extra bits .. Or that's
what I was thinking about ..

Daniel

Re: sched: 64-bit nr_running

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> > > There was a conversation over the mtd redboot bug related to unsigned 
> > > long vs. unsigned int . On a 64-bit machine unsigned long is 64-bits , 
> > > and unsigned int is 32-bits . However, both are 32-bits on a 32-bit 
> > > machine .
> > > 
> > > Looking over the scheduler I found a few places that use "unsigned 
> > > long" for task counting variables (nr_running, nr_active, 
> > > nr_interruptible) . The problem is that these variables are all bound 
> > > to 29 bits (according to kernel/pid.c) , but they get expanded to 
> > > 64-bits on 64-bit machines .
> > 
> > your point being?
> 
> We could make them unsigned int, and save the extra bits .. Or that's 
> what I was thinking about ..

well for performance it's usually best to just have the native machine 
word size (i.e. long), unless there's some compelling data-structure 
size argument. In any case it's not uncommon to use 'long' for such 
types, even though some other aspect of the kernel limits it to less 
than 64 (or even 32) bits.

	Ingo

Re: sched: 64-bit nr_running

[Daniel Walker]

On Mon, 2006-05-15 at 18:34 +0200, Ingo Molnar wrote:

> well for performance it's usually best to just have the native
> machine 
> word size (i.e. long), unless there's some compelling data-structure 
> size argument. In any case it's not uncommon to use 'long' for such 
> types, even though some other aspect of the kernel limits it to less 
> than 64 (or even 32) bits.

I also noticed that struct task_struct -> state uses a volatile long ,
but it seems to only use a few bits . exit_state also uses a long type
and only uses a few bits .. They could be combined into one long (or
even and int) .. I noticed the comment below,

 * We have two separate sets of flags: task->state
 * is about runnability, while task->exit_state are
 * about the task exiting. Confusing, but this way
 * modifying one set can't modify the other one by
 * mistake.

I think if it was all inside macro's it wouldn't be so easy to
accidentally set the exit_state when touching just state .. 

Daniel