Re: [patch 6/8] pull RT tasks

[Steven Rostedt <rostedt@goodmis.org>]

--
On Tue, 23 Oct 2007, Dmitry Adamushko wrote:

> Hi Steven,
>
> agreed with your comments in the previous message. Indeed, I missed some points.
>
> > On wakeup, we can wake up several RT tasks (as my test case does) and if
> > we only push one task, then the other tasks may not migrate over to the
> > other run queues. I logged this happening in my tests.
>
> I guess, what may happen is that while we are running push_rt_tasks()
> on CPU-k (say, as a result on try_to_wake_up(task_1))
> and as this_rq->lock may get released (in double_lock_balance()) , we
> may get in a 'race'
> with try_to_wake_up(task_2) from (another) CPU-m.
> It places a woken up task on the same run-queue (for which
> push_rt_task() is already running on CPU-k) and, actually, run
> push_rt_task() for the same rq again!
>
> So it may happen that both task_1 and task_2 will be pushed from the same CPU...
>
> Do you see an error in my description? (it's a late hour so I can miss
> something again ... sure, otherwise I'm almost perfect :-/ ) Can it
> correlate with what you have observed in your tests?
>
> Otherwise, there is 1:1 relation : push_rt_task() is called for every
> new (single) task activated by try_to_wake_up() and for a preempted
> task... so it's not like a few tasks are placed on the run-queue and
> then push_rt_tasks() is called once.
>
> btw., if this scenario may take place... maybe it would make sense to
> have something like RTLB_INPROGRESS/PENDING and to avoid competing
> push_rt_tasks() calls for the same 'rq' from different CPUs?
> (although, there can be some disadvantages here as well. e.g. we would
> likely need to remove 'max 3 tasks at once' limit and get,
> theoretically, unbounded time spent in push_rt_tasks() on a single
> CPU).

I think I see what you're saying now. That we really should do the push on
wakeup, since only the one rt task that is woken up will be able to be
pushed.

My code may seem a bit aggressive, but from logging, I see that we seldom
push more than one task. But if we don't go ahead and push more than one,
the rt-migrate-test will sometimes fail.  There's funny cases when we need
to push more than one. I can't remember exactly what they were, but
sometimes because of races between the pushes and pulls where one will
miss the fact that an RT process is being queued while its searching to
pull a task, but the push will catch it. Or vice versa.

The max tries is just a paranoid case where I don't want heavy scheduling
to cause an unbounded trying to push or pull tasks. According to the
logging while running the rt-migrate-tests, the loop there repeated
approximately 1 in 20, and iterated twice 1 in 100 and hit the third loop
twice in all my tests (over a 1000 iterations being logged). But logging
slows it down and modifies the results itself, and perhaps I'll add
statistics soon.

I'm about to post a second batch of patches.

Thanks,

-- Steve

-
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/