From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: ego@in.ibm.com
Cc: akpm@osdl.org, paulmck@us.ibm.com, mingo@elte.hu,
vatsa@in.ibm.com, dipankar@in.ibm.com,
venkatesh.pallipadi@intel.com, linux-kernel@vger.kernel.org,
oleg@tv-sign.ru
Subject: Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug
Date: Thu, 15 Feb 2007 14:31:08 +0100 [thread overview]
Message-ID: <200702151431.10068.rjw@sisk.pl> (raw)
In-Reply-To: <20070215122055.GA19155@in.ibm.com>
On Thursday, 15 February 2007 13:20, Gautham R Shenoy wrote:
> On Thu, Feb 15, 2007 at 09:09:51AM +0100, Rafael J. Wysocki wrote:
> > >
> > > Why should we make sure that PF_NOFREEZE tasks are also frozen for
> > > cpu hotplug? Instead, we can create an infrastructure which allows threads to
> > > specify for the scenarios they would want to be excempted from freeze.
> > > Something like what Paul has suggested in
> > > http://lkml.org/lkml/2007/1/31/323. That way, threads which have nothing
> > > to do with the online_cpu_map or with handling of cpu-hotplug events can
> > > mark themselves to be exempted from being frozen for cpu hotplug.
> >
> > I think all kernel threads should call try_to_freeze() in suitable places
> > anyway if we are going to use the freezer for anything more than just the
> > suspend. In other words, they all should be _able_ to freeze if necessary.
>
> Yeah! I agree. I misunderstood your earlier point. I thought you were
> hinting at freezing *everyone* while doing a cpu hotplug.
So I think tonight I'll start adding try_to_freeze() to the kernel threads that
set PF_NOFREEZE.
>
> >
> > > Once this is achieved, it's all about classifying the threads into
> > > according to their NO_FREEZE needs :)
> >
> > Yes, but I think it's just a generalization of ingoring PF_NOFREEZE.
> > If all kernel threads are able to freeze, we can mark them as "freeze for CPU
> > hotplug" or "freeze for kprobes", or "freeze for suspend" etc. and call the
> > freezer with the appropriate parameter.
> >
> > BTW, what happens to a process running on a CPU being removed?
> >
>
> We call stop_machine_run in _cpu_down which schedules an idle thread on
> the cpu to be removed. Once the idle thread runs, we call __cpu_die and
> subsequently the scheduler performs task migration while handling
> the CPU_DEAD notification (see migration_call in sched.c)
Ah, thanks for the explanation.
> > > > 2) We have to change the PM code to stop using CPU hotplug for disabling
> > > > nonboot CPUs. ;-)
> > >
> > > Just wondering, how hard is that ?
> >
> > Hmmm. In fact the problem is that the suspend code freezes tasks and then
> > calls disable_nonboot_cpus() which uses (_)cpu_down/up(). In principle we
> > could make disable_nonboot_cpus() call some lower-level routines to avoid the
> > freezing of tasks, _but_ the suspend code may freeze too few tasks (ie. we may
> > want to freeze more tasks for the CPU hotplug). Thus I think we should do
> > something like this:
> >
> > suspend: CPU hotplug:
> > freeze_processes(SUSPEND) ...
> > ... freeze_processes(CPU_HOTPLUG)
> > ... ...
> > ... thaw_processes(CPU_HOTPLUG)
> > thaw_processes(SUSPEND) ...
> >
> > so freeze_processes() should be reentrant, at least for different values of
> > the argument.
> >
>
> That would still mean going over the task list twice.
Yes, but I think this is inevitable anyway, because we have moved the
disabling of nonboot CPUs after the suspending of devices (for
ACPI-related reasons).
Currently, we have, roughly:
freeze_processes();
shrink_memory(); (swsusp only)
suspend_devices();
disable_nonboot_cpus();
suspend
and the reverse during the resume.
Still, the second pass will be quick, since the majority of tasks are frozen
when disable_nonboot_cpus() is called.
> How if we have
>
> freeze_process(SUSPEND|CPU_HOTPLUG);
> perform_pre_hotplug_suspend();
> primitive_cpu_down/_up();
> perform_post_hotplug_suspend();
>
> Does this look like a good thing to you?
> > All in all, I think we should start from modifying the freezer and the
> > classification of processes with respect to the freezing.
> >
>
> Cool! Lets get started then ;-)
No problem with that. ;-)
Speaking of the classification, do you think it would be practical to use
some kind of "freezing levels"? I mean, for each task we can define the
"freezing level" at which it should be frozen and each user of the freezer
can call it with a specific "freezing level" as a parameter. Of course for
this purpose the tasks frozen at level 1 have to be a subset of the tasks
frozen at level 2 etc. and I'm not sure if this requirement can be satisfied.
Rafael
next prev parent reply other threads:[~2007-02-15 13:35 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-14 14:40 [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug Gautham R Shenoy
2007-02-14 14:42 ` [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core Gautham R Shenoy
2007-02-14 14:43 ` [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c Gautham R Shenoy
2007-02-14 14:43 ` [RFC PATCH(Experimental) 3/4] Revert changes to sched.c and slab.c Gautham R Shenoy
2007-02-14 14:44 ` [RFC PATCH(Experimental) 4/4] Rip out lock_cpu_hotplug from linux Gautham R Shenoy
2007-02-14 14:59 ` [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c Srivatsa Vaddagiri
2007-02-14 15:24 ` Srivatsa Vaddagiri
2007-02-14 20:23 ` Oleg Nesterov
2007-02-14 20:09 ` Oleg Nesterov
2007-02-16 5:26 ` Srivatsa Vaddagiri
2007-02-16 15:33 ` Oleg Nesterov
2007-02-16 16:47 ` Srivatsa Vaddagiri
2007-02-16 18:45 ` Oleg Nesterov
2007-02-16 23:59 ` Oleg Nesterov
2007-02-17 2:29 ` Srivatsa Vaddagiri
2007-02-17 21:59 ` Oleg Nesterov
2007-02-20 15:12 ` Srivatsa Vaddagiri
2007-02-20 20:09 ` Oleg Nesterov
2007-02-21 6:29 ` Srivatsa Vaddagiri
2007-02-21 14:30 ` Oleg Nesterov
2007-02-21 14:37 ` Gautham R Shenoy
2007-02-21 15:53 ` Srivatsa Vaddagiri
2007-02-14 15:31 ` [RFC PATCH(Experimental) 1/4] freezer-cpu-hotplug core Srivatsa Vaddagiri
2007-02-14 19:47 ` Oleg Nesterov
2007-02-16 6:48 ` Srivatsa Vaddagiri
2007-02-16 15:47 ` Oleg Nesterov
2007-02-14 20:22 ` Oleg Nesterov
2007-02-16 7:16 ` Srivatsa Vaddagiri
2007-02-16 8:12 ` Srivatsa Vaddagiri
2007-02-16 9:29 ` Rafael J. Wysocki
2007-02-16 9:59 ` Srivatsa Vaddagiri
2007-02-16 11:06 ` Rafael J. Wysocki
2007-02-16 19:46 ` Oleg Nesterov
2007-02-17 2:31 ` Srivatsa Vaddagiri
2007-02-17 5:32 ` Gautham R Shenoy
2007-02-17 11:19 ` Gautham R Shenoy
2007-02-16 16:06 ` Oleg Nesterov
2007-02-14 21:43 ` [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug Rafael J. Wysocki
2007-02-15 6:34 ` Gautham R Shenoy
2007-02-15 8:09 ` Rafael J. Wysocki
2007-02-15 12:20 ` Gautham R Shenoy
2007-02-15 13:31 ` Rafael J. Wysocki [this message]
2007-02-15 14:25 ` Gautham R Shenoy
2007-02-17 11:24 ` Rafael J. Wysocki
2007-02-17 21:34 ` Oleg Nesterov
2007-02-17 22:24 ` Rafael J. Wysocki
2007-02-17 23:42 ` Oleg Nesterov
2007-02-17 23:47 ` Oleg Nesterov
2007-02-18 10:43 ` Rafael J. Wysocki
2007-02-18 11:31 ` Oleg Nesterov
2007-02-18 12:14 ` Rafael J. Wysocki
2007-02-18 14:52 ` freezer problems Oleg Nesterov
2007-02-18 15:14 ` Rafael J. Wysocki
2007-02-18 16:19 ` Oleg Nesterov
2007-02-18 18:14 ` Rafael J. Wysocki
2007-02-18 18:56 ` Rafael J. Wysocki
2007-02-18 22:01 ` Oleg Nesterov
2007-02-18 23:19 ` Rafael J. Wysocki
2007-02-19 20:23 ` Oleg Nesterov
2007-02-19 21:21 ` Rafael J. Wysocki
2007-02-19 22:41 ` Oleg Nesterov
2007-02-19 23:35 ` Rafael J. Wysocki
2007-02-20 0:12 ` Oleg Nesterov
2007-02-20 0:32 ` Rafael J. Wysocki
2007-02-20 0:50 ` Oleg Nesterov
2007-02-20 18:28 ` Rafael J. Wysocki
2007-02-20 18:29 ` Rafael J. Wysocki
2007-02-21 18:14 ` Paul E. McKenney
2007-02-21 18:13 ` Rafael J. Wysocki
2007-02-21 18:27 ` Paul E. McKenney
2007-02-21 20:03 ` Oleg Nesterov
2007-02-21 20:47 ` Rafael J. Wysocki
2007-02-21 21:06 ` Paul E. McKenney
2007-02-21 23:10 ` Rafael J. Wysocki
2007-02-22 10:47 ` Oleg Nesterov
2007-02-22 11:33 ` Oleg Nesterov
2007-02-22 17:03 ` Rafael J. Wysocki
2007-02-22 17:44 ` Oleg Nesterov
2007-02-22 21:56 ` Rafael J. Wysocki
2007-02-23 18:15 ` Oleg Nesterov
2007-02-23 3:02 ` Gautham R Shenoy
2007-02-18 15:09 ` [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug Rafael J. Wysocki
2007-02-18 16:11 ` Oleg Nesterov
2007-02-18 18:51 ` Rafael J. Wysocki
2007-02-18 10:32 ` Rafael J. Wysocki
2007-02-18 11:32 ` Oleg Nesterov
2007-02-18 12:12 ` Rafael J. Wysocki
2007-02-18 15:06 ` Oleg Nesterov
2007-02-18 12:56 ` Pavel Machek
2007-02-21 14:52 ` Gautham R Shenoy
2007-02-21 19:42 ` Pavel Machek
[not found] ` <200702231041.17136.rjw@sisk.pl>
[not found] ` <20070223100817.GA10973@in.ibm.com>
[not found] ` <200702231115.00718.rjw@sisk.pl>
[not found] ` <20070223104723.GB10973@in.ibm.com>
[not found] ` <20070223110201.GC10973@in.ibm.com>
2007-02-23 19:03 ` freezer problems Gautham R Shenoy
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=200702151431.10068.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@osdl.org \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=oleg@tv-sign.ru \
--cc=paulmck@us.ibm.com \
--cc=vatsa@in.ibm.com \
--cc=venkatesh.pallipadi@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).