lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070215063413.GA11950@in.ibm.com>
Date:	Thu, 15 Feb 2007 12:04:13 +0530
From:	Gautham R Shenoy <ego@...ibm.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	akpm@...l.org, paulmck@...ibm.com, mingo@...e.hu, vatsa@...ibm.com,
	dipankar@...ibm.com, venkatesh.pallipadi@...el.com,
	linux-kernel@...r.kernel.org, oleg@...sign.ru
Subject: Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

On Wed, Feb 14, 2007 at 10:43:35PM +0100, Rafael J. Wysocki wrote:
> Hi,
> 
> On Wednesday, 14 February 2007 15:40, Gautham R Shenoy wrote:
> > Hello Everybody,
> > 
> > This is an experiment towards process_freezer based implementation
> > of cpu-hotplug. This is mainly based on ideas of Andrew Morton, 
> > Ingo Molnar and Paul Mckenney featured in the discussion
> > http://lkml.org/lkml/2007/1/31/323.
> > 
> > This is an absolute bare-minimal implementation to check the feasibility
> > of using process freezer for cpu-hotplug. 
> > 
> > The patchset comprises of four patches.
> > o PATCH 1/4: Core implementation of freezer-based-hotplug.
> > o PATCH 2/4: Revert changes to workqueue to make it work with the
> >              freezer-cpu-hotplug.
> > o PATCH 3/4: Eliminate hotcpu subsystem mutexes from sched and slab.
> > o PATCH 4/4: Eliminate lock_cpu_hotplug from the kernel.
> 
> I think two things are missing:
> 
> 1) We should make sure there are not PF_NOFREEZE tasks running when a CPU
> is removed (when one is added probably too).  For this purpose we can add a
> parameter to freeze_processes() that will tell it to ignore PF_NOFREEZE, but
> at the same time we'll have to change all kernel threads that set PF_NOFREEZE
> to call try_to_freeze() anyway.  I can do that, but it will take me a couple of
> days.

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.

Once this is achieved, it's all about classifying the threads into
according to their NO_FREEZE needs :)

> 
> 2) We have to change the PM code to stop using CPU hotplug for disabling
> nonboot CPUs. ;-)

Just wondering, how hard is that ?

thanks
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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ