linux-kernel - Re: [PATCH v3 0/5] CPU hotplug, cpusets: Fix issues with cpusets handling during suspend/resume

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: <alpine.DEB.2.00.1205141654080.25235@chino.kir.corp.google.com>
Date:	Mon, 14 May 2012 16:58:25 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
cc:	a.p.zijlstra@...llo.nl, mingo@...nel.org, pjt@...gle.com,
	paul@...lmenage.org, akpm@...ux-foundation.org, rjw@...k.pl,
	nacc@...ibm.com, paulmck@...ux.vnet.ibm.com, tglx@...utronix.de,
	seto.hidetoshi@...fujitsu.com, tj@...nel.org, mschmidt@...hat.com,
	berrange@...hat.com, nikunj@...ux.vnet.ibm.com,
	vatsa@...ux.vnet.ibm.com, liuj97@...il.com,
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH v3 0/5] CPU hotplug, cpusets: Fix issues with cpusets
 handling during suspend/resume

On Mon, 14 May 2012, Srivatsa S. Bhat wrote:

> Currently the kernel doesn't handle cpusets properly during suspend/resume.
> After a resume, all non-root cpusets end up having only 1 cpu (the boot cpu),
> causing massive performance degradation of workloads. One major user of cpusets
> is libvirt, which means that after a suspend/hibernation cycle, all VMs
> suddenly end up running terribly slow!
> 
> Also, the kernel moves the tasks from one cpuset to another during CPU hotplug
> in the suspend/resume path, leading to a task-management nightmare after
> resume.
> 

To deal with mempolicy rebinding when a cpuset changes, I made a change to 
mempolicies to store the user nodemask passed to set_mempolicy() or 
mbind() so the intention of the user could be preserved.  It seems like 
you should do the same thing for cpusets to store the "intended" set of 
cpus and respect that during cpu online?

> Patches 1 & 2 are cleanups that separate out hotplug handling so that we can
> implement different logic for different hotplug events (CPU/Mem
> online/offline). This also leads to some optimizations and more importantly
> prepares the ground for any further work dealing with cpusets during hotplug.
> 
> Patch 3 is a bug fix - it ensures that the tasks attached to the root cpuset
> see the updated cpus_allowed mask upon CPU hotplug.
> 
> Patches 4 and 5 implement the fix for cpusets handling during suspend/resume.

All of your patches are labeled to stable@...r.kernel.org, but I seriously 
doubt any of this is stable material since it has been a long-standing 
issue (and perhaps intentional in some cases) and your series includes 
cleanups and optimizations that wouldn't be stable candidates, so I'd 
suggest removing that annotation.
--
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/