On Thu, Feb 15, 2007 at 02:31:08PM +0100, Rafael J. Wysocki wrote:
>
> So I think tonight I'll start adding try_to_freeze() to the kernel threads that
> set PF_NOFREEZE.
cool! While you are at it, let me try to enhance the freezer api's
to incorporate the PFE_* flags.
> >
> > 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.
Ok. That's fine by me. Lets get it working first. We can always optimize
it later :-)
> >
> > 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.
A freeze hierarchy! I hope this freeze_level parameter ain't an alternative
to the PFE_* flags because then a task would be in a dilemma as to
what freezing level it should be at, if it wants to be frozen for lets
say kprobes but not for cpu-hotplug. Cpu-hotplug and kprobes
may not have a dependency like the one that exists between cpu-hotplug
and suspend. So, at this moment, even I am not sure if there is a
need for the hierarchy.
>
> Rafael
Thanks and Regards
gautham.
--
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
