linux-kernel - Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200701301744.48601.rjw@sisk.pl>
Date:	Tue, 30 Jan 2007 17:44:47 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Ingo Molnar <mingo@...e.hu>, Andrew Morton <akpm@...l.org>,
	dipankar@...ibm.com, Gautham Shenoy <ego@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

On Tuesday, 30 January 2007 17:02, Paul E. McKenney wrote:
> On Tue, Jan 30, 2007 at 08:33:40AM +0100, Ingo Molnar wrote:
> > 
> > * Paul E. McKenney <paulmck@...ux.vnet.ibm.com> wrote:
> > 
> > > > in fact (new) kprobes uses the freezer, and it's far more 
> > > > performance sensitive than the handling of CPU hotplug events.
> > > 
> > > Outside of realtime workloads, I agree that performance should not be 
> > > a problem.  And I don't know of any reason why realtime systems need 
> > > to be able to do hotplug CPU.  Yet, anyway.  ;-)
> > 
> > even for -rt it's not really an issue: the hotplug locks are so 
> > all-encompassing and so unbound at the moment that there's no realistic 
> > expectation for them to ever become deterministic. So we might as well 
> > make them encompass "everything" - without any noticeable effect.
> > 
> > > So the thought is to make _cpu_down() and _cpu_up() do something like 
> > > the following (untested, probably does not even compile), perhaps with 
> > > suitable adjustments elsewhere as well?
> > > 
> > > 	static int _cpu_down(unsigned int cpu)
> > > 	{
> > > 		int err;
> > > 		struct task_struct *p;
> > > 		cpumask_t old_allowed, tmp;
> > > 
> > > 		if (num_online_cpus() == 1)
> > > 			return -EBUSY;
> > > 
> > > 		if (!cpu_online(cpu))
> > > 			return -EINVAL;
> > > 
> > > 		if (freeze_processes()) {
> > > 			err = -EBUSY;
> > > 			goto out_freeze_notify_failed;
> > > 		}
> > > 		err = raw_notifier_call_chain(&cpu_chain, CPU_DOWN_PREPARE,
> > > 							(void *)(long)cpu);
> > 
> > yeah. This all looks so nice that i almost cannot believe it's true :-) 
> 
> Well, it turns out that maybe it is in fact untrue.  :-/
> 
> I need to look at all uses of PF_NOFREEZE -- as I understand the
> code, processes marked PF_NOFREEZE will continue running, potentially
> interfering with the hotplug operation.  :-(
> 
> I will pass my findings on to this list.

Well, I did it some time ago, although not very thoroughly.

AFAICS there are not so many, but one that stands out is the worker threads.
We needed two of them to actually go to sleep, so now it's possible to create
a "freezeable workqueue" the worker thread of which will not set PF_NOFREEZE,
but currently this is only used by XFS.

Greetings,
Rafael


-- 
If you don't have the time to read,
you don't have the time or the tools to write.
		- Stephen King
-
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/