From: Oleg Nesterov <oleg@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: linux-kernel@vger.kernel.org, rusty@rustcorp.com.au,
sivanich@sgi.com, heiko.carstens@de.ibm.com,
torvalds@linux-foundation.org, mingo@elte.hu,
peterz@infradead.org, dipankar@in.ibm.com, josh@freedesktop.org,
paulmck@linux.vnet.ibm.com, akpm@linux-foundation.org
Subject: Re: [PATCH 1/4] cpuhog: implement cpuhog
Date: Mon, 8 Mar 2010 20:01:42 +0100 [thread overview]
Message-ID: <20100308190142.GA9149@redhat.com> (raw)
In-Reply-To: <1268063603-7425-2-git-send-email-tj@kernel.org>
On 03/09, Tejun Heo wrote:
>
> Implement a simplistic per-cpu maximum priority cpu hogging mechanism
> named cpuhog. A callback can be scheduled to run on one or multiple
> cpus with maximum priority monopolozing those cpus. This is primarily
> to replace and unify RT workqueue usage in stop_machine and scheduler
> migration_thread which currently is serving multiple purposes.
>
> Four functions are provided - hog_one_cpu(), hog_one_cpu_nowait(),
> hog_cpus() and try_hog_cpus().
>
> This is to allow clean sharing of resources among stop_cpu and all the
> migration thread users. One cpuhog thread per cpu is created which is
> currently named "hog/CPU". This will eventually replace the migration
> thread and take on its name.
Heh. In no way I can ack (or even review) the changes in sched.c, but
personally I like this idea.
And I think cpuhog can have more users. Say, wait_task_context_switch()
could use hog_one_cpu() to force the context switch instead of looping,
perhaps.
A simple question,
> +struct cpuhog_done {
> + atomic_t nr_todo; /* nr left to execute */
> + bool executed; /* actually executed? */
> + int ret; /* collected return value */
> + struct completion completion; /* fired if nr_todo reaches 0 */
> +};
> +
> +static void cpuhog_signal_done(struct cpuhog_done *done, bool executed)
> +{
> + if (done) {
> + if (executed)
> + done->executed = true;
> + if (atomic_dec_and_test(&done->nr_todo))
> + complete(&done->completion);
> + }
> +}
So, ->executed becomes T if at least one cpuhog_thread() thread calls ->fn(),
> +int __hog_cpus(const struct cpumask *cpumask, cpuhog_fn_t fn, void *arg)
> +{
> ...
> +
> + wait_for_completion(&done.completion);
> + return done.executed ? done.ret : -ENOENT;
> +}
Is this really right?
I mean, perhaps it makes more sense if ->executed was set only if _all_
CPUs from cpumask "ack" this call?
I guess, currently this doesn't matter, stop_machine() uses cpu_online_mask
and we can't race with hotplug.
Oleg.
next prev parent reply other threads:[~2010-03-08 19:04 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-08 15:53 [PATCHSET] cpuhog: implement and use cpuhog Tejun Heo
2010-03-08 15:53 ` [PATCH 1/4] cpuhog: implement cpuhog Tejun Heo
2010-03-08 19:01 ` Oleg Nesterov [this message]
2010-03-08 23:18 ` Tejun Heo
2010-03-08 15:53 ` [PATCH 2/4] stop_machine: reimplement using cpuhog Tejun Heo
2010-03-08 16:32 ` Arjan van de Ven
2010-03-08 23:21 ` Tejun Heo
2010-03-08 17:10 ` Heiko Carstens
2010-03-08 18:27 ` Oleg Nesterov
2010-03-08 19:37 ` Heiko Carstens
2010-03-08 23:39 ` Tejun Heo
2010-03-09 7:09 ` Heiko Carstens
2010-03-09 7:16 ` Tejun Heo
2010-03-08 19:06 ` Oleg Nesterov
2010-03-08 23:22 ` Tejun Heo
2010-03-08 15:53 ` [PATCH 3/4] scheduler: replace migration_thread with cpuhog Tejun Heo
2010-03-08 15:53 ` [PATCH 4/4] scheduler: kill paranoia check in synchronize_sched_expedited() Tejun Heo
2010-03-10 19:25 ` [PATCHSET] cpuhog: implement and use cpuhog Peter Zijlstra
2010-03-12 3:13 ` Tejun Heo
2010-03-29 6:46 ` Rusty Russell
2010-03-29 9:11 ` Peter Zijlstra
2010-04-02 5:45 ` Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2010-03-17 8:40 [PATCHSET sched/core] cpuhog: implement and use cpuhog, take#2 Tejun Heo
2010-03-17 8:40 ` [PATCH 1/4] cpuhog: implement cpuhog Tejun Heo
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=20100308190142.GA9149@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dipankar@in.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=josh@freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rusty@rustcorp.com.au \
--cc=sivanich@sgi.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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.