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: <20070129024026.GI4908@linux.vnet.ibm.com>
Date:	Sun, 28 Jan 2007 18:40:26 -0800
From:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	dipankar@...ibm.com, Gautham Shenoy <ego@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Fw: Re: [mm PATCH 4/6] RCU: (now) CPU hotplug

On Sun, Jan 28, 2007 at 03:30:05PM -0800, Andrew Morton wrote:
> On Sun, 28 Jan 2007 14:47:56 -0800
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
> 
> > > If we use the process freezer, these bugs all get automatically fixed,
> > > and we get to remove the existing locking, and we don't need to think
> > > about it any more.
> > 
> > The idea being to essentially suspend the system to RAM, remove the
> > CPU and then unsuspend it?  Seems like quite high overhead -- or am
> > I misunderstanding the proposal?
> 
> The process freezer basically wakes up all threads in the machine and makes
> them go to sleep in a specific place, so they're all in a known state. 
> kernel threads are also captured, via their open-coded polling call to
> try_to_freeze().
> 
> The machine suspend code uses the process freezer, as does kprobes.  The
> freezer isn't tied to suspend or to power management.
> 
> The freezer does have potential to be expensive if used frequently and if
> there are many threads.  But I don't think anyone has looked at optimising
> it.  For example, there are certain places in the kernel where threads
> commonly sleep (eg, select()).  We know that this is a safe place to sleep
> wrt (at least) CPU hotplug, so there's not really a need to wake those
> processes up.  Perhaps something could be done with that observation...
> 
> But first we'd need to demonstrate that we actually have a problem.

Fair enough -- though if it is a goal to remove CPUs from systems with
realtime workloads, I can assure you that we do have a problem.

						Thanx, Paul
-
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/