How does 2.6 SMP scheduler initially assign a thread to a run queue?

How does 2.6 SMP scheduler initially assign a thread to a run queue?

[helen monte]

In the 2.6 kernel, there is one run queue per CPU, in case of an SMP.
After a thread is created, how does the scheduler determine which run
queue it goes to?  I know that once it goes to a particular run queue,
the scheduler would try to run that thread on that CPU to take
advantage of processor affinity; and then there would be the load
balancing stuff.  But at the very beginning, what algorithm does the
scheduler use to assign a newly created thread to a particulat CPU?
Would the load balancing algorithm be used? Or gang scheduling?
By the way, in an SMT/hyperthreading processor, does the latest kernel
version assign one run queue per physical CPU, or per virtual processor?

Re: How does 2.6 SMP scheduler initially assign a thread to a run queue?

[lk]

> 
> In the 2.6 kernel, there is one run queue per CPU, in case of an SMP.
> After a thread is created, how does the scheduler determine which run
> queue it goes to?  

First it forked process (child) gets the same CPU as that of parent.
forking a child gets the same CPU and later part of fork will call 
wake_up_new_task () to fetch the run-queue of the CPU and 
__activate_task () is called to move task into run-queue. 
Later rescheduling of the process may move process to another
run-queues.

>I know that once it goes to a particular run queue,
> the scheduler would try to run that thread on that CPU to take
> advantage of processor affinity; and then there would be the load
> balancing stuff.  But at the very beginning, what algorithm does the
> scheduler use to assign a newly created thread to a particulat CPU?

Child will always goes to the parent's run-queue (CPU) for the first time.

> Would the load balancing algorithm be used? Or gang scheduling?

Yes, load balancing algorithm is used. tasks will be pulled from
very busy processors to lesser busy processors.

> By the way, in an SMT/hyperthreading processor, does the latest kernel
> version assign one run queue per physical CPU, or per virtual 
> processor?
> 

one run-queue per physical CPU

regards
lk

Re: How does 2.6 SMP scheduler initially assign a thread to a run queue?

[Siddha, Suresh B]

On Wed, Jun 08, 2005 at 06:11:55PM +0530, lk wrote:
> > In the 2.6 kernel, there is one run queue per CPU, in case of an SMP.
> > After a thread is created, how does the scheduler determine which run
> > queue it goes to?  
> 
> First it forked process (child) gets the same CPU as that of parent.
> forking a child gets the same CPU and later part of fork will call 
> wake_up_new_task () to fetch the run-queue of the CPU and 
> __activate_task () is called to move task into run-queue. 
> Later rescheduling of the process may move process to another
> run-queues.

In -mm kernels, Nick has recently added balance on exec/fork.

> > By the way, in an SMT/hyperthreading processor, does the latest kernel
> > version assign one run queue per physical CPU, or per virtual 
> > processor?
> > 
> 
> one run-queue per physical CPU

No. Each logical processor has its own runqueue.

thanks,
suresh

Re: How does 2.6 SMP scheduler initially assign a thread to a run queue?

[Steven Rostedt]

On Wed, 2005-06-08 at 12:03 -0700, Siddha, Suresh B wrote:

> > > By the way, in an SMT/hyperthreading processor, does the latest kernel
> > > version assign one run queue per physical CPU, or per virtual 
> > > processor?
> > > 
> > 
> > one run-queue per physical CPU
> 
> No. Each logical processor has its own runqueue.

I think it is also worth mentioning that the sched domains are used to
help keep processes on the same physical CPU. Little cost associated to
moving a process from one logical CPU to a sibling, where as there is a
big cost in moving it to another physical CPU.

-- Steve

How does 2.6 SMP scheduler assign runqueues to multi-cores?

[helen monte]

> > > > By the way, in an SMT/hyperthreading processor, does the latest 
>kernel
> > > > version assign one run queue per physical CPU, or per virtual 
>processor?
> > > >
> > > one run-queue per physical CPU
> >
> > No. Each logical processor has its own runqueue.

How about muti-core?  Does each core also have its own run queue?  Does 
anyone know how multi-core would work with SMT?  Is it possible that they 
work together?  Is the following a possible scenario? :  A node has two 
processors, each processor has two cores, and each core has two "virtual 
cores". And there are 8 run queues in total.

Re: How does 2.6 SMP scheduler assign runqueues to multi-cores?

[Nick Piggin]

On Thu, 2005-06-09 at 06:32 +0000, helen monte wrote:
> > > > > By the way, in an SMT/hyperthreading processor, does the latest 
> >kernel
> > > > > version assign one run queue per physical CPU, or per virtual 
> >processor?
> > > > >
> > > > one run-queue per physical CPU
> > >
> > > No. Each logical processor has its own runqueue.
> 
> How about muti-core?  Does each core also have its own run queue?  Does 
> anyone know how multi-core would work with SMT?  Is it possible that they 
> work together?  Is the following a possible scenario? :  A node has two 
> processors, each processor has two cores, and each core has two "virtual 
> cores". And there are 8 run queues in total.
> 

It is always one runqueue per virtual CPU, so dual core has 2 runqueues,
and dual core with SMT has 4 runqueues.

IBM and I believe Intel have chips that support SMT and have 2 cores.

-- 
SUSE Labs, Novell Inc.



Send instant messages to your online friends http://au.messenger.yahoo.com