From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: Only CPU0 active after ACPI S3, xen 4.1.3 Date: Wed, 16 Jan 2013 13:58:07 +0000 Message-ID: <50F6B1EF.9020100@eu.citrix.com> References: <50B7AF8A.5010304@invisiblethingslab.com> <50BC653E02000078000AD28C@nat28.tlf.novell.com> <50BDFA38.7030009@invisiblethingslab.com> <50D335E6.902@invisiblethingslab.com> <50D39C73.906@invisiblethingslab.com> <50D3EB03.4000109@invisiblethingslab.com> <50D4322102000078000B1F80@nat28.tlf.novell.com> <50D46534.2010304@invisiblethingslab.com> <50D4757202000078000B2042@nat28.tlf.novell.com> <50D46B47.8000003@invisiblethingslab.com> <50D48090.6060603@invisiblethingslab.com> <50D4967602000078000B2114@nat28.tlf.novell.com> <3368417890369848263@unknownmsgid> <50D6713C.2000202@invisiblethingslab.com> <50E554CC02000078000B29BD@nat28.tlf.novell.com> <50F68D8F.7030704@eu.citrix.com> <50F695DB.6000402@eu.citrix.com> <50F6B44702000078000B6459@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50F6B44702000078000B6459@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Ben Guthro , Marek Marczykowski , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 16/01/13 13:08, Jan Beulich wrote: >>>> On 16.01.13 at 12:58, George Dunlap wrote: >> On 16/01/13 11:22, George Dunlap wrote: >>> Jan, the commit message isn't very informative -- can you point me to > Which commit message? > >>> a conversation describing the problem you're fixing wrt >>> suspend/resume, and/or describe what you were trying to do? Given the >>> results, the whole thing about not disabling scheduling during suspend >>> seems a bit suspect... >> In particular, just on a fairly cursory bit of function call skimming, >> it looks like: >> * This change means that cpupool.c:cpu_callback() won't call >> cpupool_cpu_add() when resuming >> * cpupool_cpu_add() does a bunch of paperwork (which would be >> unnecessary given the changes re suspend), but also calls >> cpupool_assign_cpu_locked() >> * cpupool_assign_cpu_locked() calls schedule_cpu_switch() >> * schedule_cpu_switch() calls the scheduler's tick_resume() >> >> So is it possible that on resume ticks are not being re-enabled, or >> something like that? > I don't see a problem here - it's symmetric (nothing done on > suspend, and nothing done on resume). Well it would be if it was only data, but it's not. That's my point. Before this changeset (xen-unstable 25079:d5ccb2d1dbd1), ticks were suspended and resumed on the CPU (i.e., timer interrupts turned off and on), and after the patch, they're not. Doesn't suspend disable / muck with timer interrupts? -George