Re: [Lse-tech] Node affine NUMA scheduler extension

Martin J. Bligh (mbligh@aracnet.com)
Tue, 27 May 2003 14:51:54 -0700


--Erich Focht <efocht@hpce.nec.com> wrote (on Tuesday, May 27, 2003 23:28:27 +0200):

> On Tuesday 27 May 2003 17:38, Martin J. Bligh wrote:
>> > Interesting observation, I didn't make it when I tried the lazy
>> > homenode (quite a while ago). But I was focusing on MPI jobs. So what
>> > if we add a condition to CAN_MIGRATE which disables the cache affinity
>> > before the first load balance?
> ...
>>
>> It'd be nice not to require user intervention here ... is it OK to
>> set CAN_MIGRATE for all clone operations?
>
> Do you think of something like:
>
># define CAN_MIGRATE_TASK(p,rq,this_cpu) \
> (HOMENODE_UNSET(p) && \ //<--
> (jiffies - (p)->last_run > cache_decay_ticks) && \
> !task_running(rq, p) && \
> ((p)->cpus_allowed & (1UL << (this_cpu))))
>
> curr = curr->prev;
>
> if (!CAN_MIGRATE_TASK(tmp, busiest, this_cpu)
> || !numa_should_migrate(tmp, busiest, this_cpu)) {
> if (curr != head)
> goto skip_queue;
> idx++;
> goto skip_bitmap;
> }
> if (HOMENODE_UNSET(tmp)) //<--
> set_task_node(tmp,cpu_to_node(this_cpu)); //<--
> pull_task(busiest, array, tmp, this_rq, this_cpu);
> if (!idle && --imbalance) {
> ...
>
> ?
> Guess this would help a bit for multithreaded jobs. Chosing the
> homenode more carefully here would be pretty expensive.

My first instinct is that #define'ing CAN_MIGRATE_TASK in the midst
of a function needs to die a horrible death ;-) But you didn't start
that one, so other than that ...

My instinct would tell me the first expression should be ||, not &&
but I'm not 100% sure. And is this restricted to just clones? Doesn't
seem to be, unless that's implicit in homenode_unset?

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/