Re: [Lse-tech] Re: CPU affinity & IPI latency

From: Mike Kravetz (
Date: Mon Jul 16 2001 - 10:46:11 EST

On Sun, Jul 15, 2001 at 10:15:42PM +0200, Andi Kleen wrote:
> On Fri, Jul 13, 2001 at 03:43:05PM -0700, Mike Kravetz wrote:
> > - Define a new field in the task structure 'saved_cpus_allowed'.
> > With a little collapsing of existing fields, there is room to put
> > this on the same cache line as 'cpus_allowed'.
> > - In reschedule_idle() if we determine that the best CPU for a task
> > is the CPU it is associated with (p->processor), then temporarily
> > bind the task to that CPU. The task is temporarily bound to the
> > CPU by overwriting the 'cpus_allowed' field such that the task can
> > only be scheduled on the target CPU. Of course, the original
> > value of 'cpus_allowed' is saved in 'saved_cpus_allowed'.
> > - In schedule(), the loop which examines all tasks on the runqueue
> > will restore the value of 'cpus_allowed'.
> This sounds racy, at least with your simple description. Even other CPUs
> could walk their run queue while the IPI is being processed and reset the
> cpus_allowed flag too early. I guess it would need a check in the
> schedule loop that restores cpus_allowed that the current CPU is the only
> on set in that task's cpus_allowed.

You are correct. It is trivial to allow only the 'target' CPU to reset
the cpus_allowed field. This was my first thought. However, as you
state below we would get into trouble if there was an extremely long
delay in that CPU running schedule.

The timestamp sounds reasonable, but I was trying to keep it as simple
as possible.

> This unfortunately would hang the
> process if the CPU for some reason cannot process schedules timely, so
> it may be needed to add a timestamp also to the task_struct that allows
> the restoration of cpus_allowed even from non target CPUs after some
> time.

Mike Kravetz                       
IBM Linux Technology Center
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 21:00:07 EST