Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3324498imm; Fri, 25 May 2018 03:52:34 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrhEmtGcrfxzQxcIwSPgeFgtCgHvuvwBRALCGU+Nws3gH3m9OiCELLf7WtJwbeebN6iHXqD X-Received: by 2002:a17:902:57d0:: with SMTP id g16-v6mr2086815plj.222.1527245554501; Fri, 25 May 2018 03:52:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527245554; cv=none; d=google.com; s=arc-20160816; b=b3HE8IRnCEdL6r4Hbq/oPLWJaUlNdaqe4WphYxsvR2lVvYwARBtDcoc8aLIuKr7wXG CsDFpNFjL/6HlpixO+FJ1XmfJO9dngXdeyUJImxz4OfQAb1k674U1T9y1Y/iY9+ujw3l P3MBoIEAaS2dxarUT3THkxHQqCAHNfIjY2N2jh9dRza8kDx35TjzMGEadkzb8gldirx4 Zp5nd2tdq0oS+l4FMse7BZPrpgf79X2pKo98tzqBKnC914M7AgAbWIfQeOQZdJ9u/D7Z OfAMisxQzt4/hBR2mmj/g9H+EsmBjLtfILpKgtmT/Lcx/RCIoIChG5uzSNIcEoi4PC/7 KpMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=W2HOtfCXkZkRI86VkkTjPM2scXn/AVuo+kSL998juYU=; b=gYy4YW8KdTWyFQfaPUyUaa98XwXNJymPnxyQXrH8TOfgwuYqiBPX4e2RagMuxflD/Y 4Xt9GYIGP6TziRzoh07UYb+bZDL1PH+rCSaJ5UVnDLVgW3eHrGLljL4E9izV0bOntiwR twfEggKvi63hTKgPvPY4OJ18FD6mujX7Zp4nOysf4vOb4mE+5P/QzA2lTcrpdHPM0DK0 0+VDR3aT5OAEfytDiCwIwoI2nQoLpo7+okPZo5UFu9BvMnNxNOOhcwVXC9kb2k7aqzNP jV7IBr1pOSnp08LJaFJAWnVKwrDznSp8hrSvGIkcsfyCXdOAZ5nomlLFMwcjdxvb3gMC rZ0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k1-v6si1320442pgr.13.2018.05.25.03.52.19; Fri, 25 May 2018 03:52:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965943AbeEYKuq (ORCPT + 99 others); Fri, 25 May 2018 06:50:46 -0400 Received: from ozlabs.org ([203.11.71.1]:53823 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965554AbeEYKup (ORCPT ); Fri, 25 May 2018 06:50:45 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPSA id 40sjhh0tP6z9s0q; Fri, 25 May 2018 20:50:44 +1000 (AEST) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=ellerman.id.au From: Michael Ellerman To: Akshay Adiga , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: npiggin@gmail.com, ego@linux.vnet.ibm.com, Akshay Adiga Subject: Re: [PATCH] cpuidle/powernv : init all present cpus for deep states In-Reply-To: <1526472134-23757-1-git-send-email-akshay.adiga@linux.vnet.ibm.com> References: <1526472134-23757-1-git-send-email-akshay.adiga@linux.vnet.ibm.com> Date: Fri, 25 May 2018 20:50:43 +1000 Message-ID: <87fu2gqa9o.fsf@concordia.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Akshay Adiga writes: > Init all present cpus for deep states instead of "all possible" cpus. > Init fails if the possible cpu is gaurded. Resulting in making only > non-deep states available for cpuidle/hotplug. This is basically the opposite of what we just did for IMC. There we switched from present to possible, to make it work when some CPUs are guarded. Which makes me think we need a better way of dealing with guarded CPUs, because working out which code should use present or possible seems to be basically trial-and-error. I'm not actually sure why Guarded CPUs are showing up as possible but not present, did we do that on purpose or is it just happening by accident? I can merge this, but we need to make this less bug prone in future. cheers > diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c > index 1f12ab1..1c5d067 100644 > --- a/arch/powerpc/platforms/powernv/idle.c > +++ b/arch/powerpc/platforms/powernv/idle.c > @@ -79,7 +79,7 @@ static int pnv_save_sprs_for_deep_states(void) > uint64_t msr_val = MSR_IDLE; > uint64_t psscr_val = pnv_deepest_stop_psscr_val; > > - for_each_possible_cpu(cpu) { > + for_each_present_cpu(cpu) { > uint64_t pir = get_hard_smp_processor_id(cpu); > uint64_t hsprg0_val = (uint64_t)paca_ptrs[cpu]; > > @@ -814,7 +814,7 @@ static int __init pnv_init_idle_states(void) > int cpu; > > pr_info("powernv: idle: Saving PACA pointers of all CPUs in their thread sibling PACA\n"); > - for_each_possible_cpu(cpu) { > + for_each_present_cpu(cpu) { > int base_cpu = cpu_first_thread_sibling(cpu); > int idx = cpu_thread_in_core(cpu); > int i; > -- > 2.5.5