From: Oleg Nesterov <oleg@tv-sign.ru>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC] Thread Migration Preemption - v2
Date: Wed, 11 Jul 2007 20:36:48 +0400 [thread overview]
Message-ID: <20070711163648.GA232@tv-sign.ru> (raw)
In-Reply-To: <20070711044915.GA4025@Krystal>
On 07/11, Mathieu Desnoyers wrote:
>
> This patch adds the ability to protect critical sections from migration to
> another CPU without disabling preemption.
>
> This will be useful to minimize the amount of preemption disabling for the -rt
> patch. It will help leveraging improvements brought by the local_t types in
> asm/local.h (see Documentation/local_ops.txt). Note that the updates done to
> variables protected by migrate_disable must be either atomic or protected from
> concurrent updates done by other threads.
>
> Typical use:
>
> migrate_disable();
> local_inc(&__get_cpu_var(&my_local_t_var));
> migrate_enable();
>
> Which will increment the variable atomically wrt the local CPU.
Well, I am not a maintainer, but I personally think this patch is too complex.
Mathieu, please use "diff -p", it is very difficult to read it. I am not sure
I understand this patch correctly, I don't have a -git tree.
> static int __migrate_task(struct task_struct *p, int src_cpu, int dest_cpu)
> {
> @@ -4829,13 +4888,19 @@
>
> double_rq_lock(rq_src, rq_dest);
> /* Already moved. */
> - if (task_cpu(p) != src_cpu)
> + if (task_cpu(p) != src_cpu) {
> + ret = 1;
> goto out;
> + }
This is a strange change. Why we return success when migration failed ?
OK, I guess this is a special hack for the modified migration_thread()...
> /* Affinity changed (again). */
> if (!cpu_isset(dest_cpu, p->cpus_allowed))
> goto out;
>
> on_rq = p->se.on_rq;
> +#ifdef CONFIG_PREEMPT
> + if (!on_rq && task_thread_info(p)->migrate_count)
> + goto out;
> +#endif
This means that move_task_off_dead_cpu() will spin until the task will be scheduled
on the dead CPU. Given that we hold tasklist_lock and irqs are disabled, this may
never happen.
(This patch adds a lot of #ifdef's, I think it could be simplified if you add
get_migrate_count() which is defined as 0 when !CONFIG_PREEMPT).
> @@ -4891,10 +4957,22 @@
> list_del_init(head->next);
>
> spin_unlock(&rq->lock);
> - __migrate_task(req->task, cpu, req->dest_cpu);
> + migrated = __migrate_task(req->task, cpu, req->dest_cpu);
> local_irq_enable();
> -
> - complete(&req->done);
> + if (!migrated) {
> + /*
> + * If the process has not been migrated, let it run
> + * until it reaches a migration_check() so it can
> + * wake us up.
> + */
> + spin_lock_irq(&rq->lock);
> + head = &rq->migration_queue;
> + list_add(&req->list, head);
> + set_tsk_thread_flag(req->task, TIF_NEED_MIGRATE);
> + spin_unlock_irq(&rq->lock);
> + wake_up_process(req->task);
> + } else
> + complete(&req->done);
I guess this is migration_thread(). The wake_up_process(req->task) looks strange,
why? It can't help if the task waits for the event/mutex.
And this is racy. What if check_migrate() is in progress, and the task has already
checked TIF_NEED_MIGRATE?
Hm. We re-add "req" to rq->migration_queue. This means that migration_thread() will
do a busy-wait loop. Not good and deadlockable, migration/X is SCHED_FIFO.
And what if __migrate_task() failed because ->cpus_allowed was changed in between?
Oleg.
next prev parent reply other threads:[~2007-07-11 16:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-06 6:02 [RFC] Thread Migration Preemption Oleg Nesterov
2007-07-06 14:23 ` Mathieu Desnoyers
2007-07-06 14:56 ` Oleg Nesterov
2007-07-11 4:49 ` [RFC] Thread Migration Preemption - v2 Mathieu Desnoyers
2007-07-11 16:36 ` Oleg Nesterov [this message]
2007-07-14 18:27 ` Mathieu Desnoyers
2007-07-14 19:56 ` Oleg Nesterov
2007-07-14 18:40 ` [RFC] Thread Migration Preemption - v3 Mathieu Desnoyers
2007-07-14 18:42 ` [RFC] Thread Migration Preemption - v4 Mathieu Desnoyers
2007-07-14 19:14 ` Peter Zijlstra
2007-07-14 20:25 ` Mathieu Desnoyers
2007-07-14 19:30 ` Peter Zijlstra
2007-07-14 20:26 ` Mathieu Desnoyers
2007-07-14 20:23 ` Oleg Nesterov
2007-07-14 20:33 ` Mathieu Desnoyers
2007-07-14 20:42 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070711163648.GA232@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.