From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756708AbbBEHyV (ORCPT ); Thu, 5 Feb 2015 02:54:21 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:51298 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750838AbbBEHyU (ORCPT ); Thu, 5 Feb 2015 02:54:20 -0500 MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 X-AuditID: cbfec7f4-b7f126d000001e9a-30-54d3211768b8 Content-transfer-encoding: 8BIT Message-id: <1423122855.29408.13.camel@AMDC1943> Subject: Re: [PATCH] ARM: Don't use complete() during __cpu_die From: Krzysztof Kozlowski To: Stephen Boyd Cc: Russell King , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Rutland , paulmck@linux.vnet.ibm.com, Arnd Bergmann , Bartlomiej Zolnierkiewicz , Fengguang Wu , Marek Szyprowski Date: Thu, 05 Feb 2015 08:54:15 +0100 In-reply-to: <54D2A06B.70507@codeaurora.org> References: <1423068835-25470-1-git-send-email-k.kozlowski@samsung.com> <54D2A06B.70507@codeaurora.org> X-Mailer: Evolution 3.10.4-0ubuntu2 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsVy+t/xy7riipdDDOb3K1n8nXSM3WLjjPWs Fu+fr2e22PT4GqvF5V1z2CxuX+a1WHvkLrvF0usXmSzebv7OavHjTDeLA5fHmnlrGD1amnvY PH7/msTocbmvl8lj8Z6XTB4PDm1m8di8pN6jb8sqRo/Pm+QCOKO4bFJSczLLUov07RK4Mpa2 r2AuuKlTMXHGX9YGxnPKXYycHBICJhJ39rezQthiEhfurWfrYuTiEBJYyijxf/5ERpAEr4Cg xI/J91i6GDk4mAXkJY5cygYJMwuoS0yat4gZov4zo8Sj77NYQWp4BQwk1kx2B6kRFrCX6Pw0 nQnEZhMwlti8fAkbiC0C1Pt9x0k2iDmPmSSaz7uA2CwCqhK7j3eBxTkFdCRe7b3JDGILCWRK fJ/6lxlkvISAskRjv9sERoFZSI6bhXDcLCTHLWBkXsUomlqaXFCclJ5rqFecmFtcmpeul5yf u4kREiFfdjAuPmZ1iFGAg1GJh7eh7WKIEGtiWXFl7iFGCQ5mJRFeTY7LIUK8KYmVValF+fFF pTmpxYcYmTg4pRoYRSbev8KSftc2c9LUuq0T2d4KFfrodfeccZw4a11B1x2JEvcp7Jk7Viiy /k+ItD4QbpR5bG3EPg+2xQslMz6+e6H2v+STtqPGTH2u9c+VLzNv/zg18JtSz5eEfzv+lNcy et5aV7j4+Z0iAUmtF2fT2xpq/ds35k1gXupvW8ewW01TQSfwXAibEktxRqKhFnNRcSIAVuDW 624CAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On śro, 2015-02-04 at 14:42 -0800, Stephen Boyd wrote: > On 02/04/15 08:53, Krzysztof Kozlowski wrote: > > The complete() should not be used on offlined CPU. Rewrite the > > wait-complete mechanism with wait_on_bit_timeout(). > > > > The CPU triggering hot unplug (e.g. CPU0) will loop until some bit is > > cleared. In each iteration schedule_timeout() is used with initial sleep > > time of 1 ms. Later it is increased to 10 ms. > > > > The dying CPU will clear the bit which is safe in that context. > > > > This fixes following RCU warning on ARMv8 (Exynos 4412, Trats2) during > > suspend to RAM: > > > > [ 31.113925] =============================== > > [ 31.113928] [ INFO: suspicious RCU usage. ] > > [ 31.113935] 3.19.0-rc7-next-20150203 #1914 Not tainted > > [ 31.113938] ------------------------------- > > [ 31.113943] kernel/sched/fair.c:4740 suspicious rcu_dereference_check() usage! > > [ 31.113946] > > [ 31.113946] other info that might help us debug this: > > [ 31.113946] > > [ 31.113952] > > [ 31.113952] RCU used illegally from offline CPU! > > [ 31.113952] rcu_scheduler_active = 1, debug_locks = 0 > > [ 31.113957] 3 locks held by swapper/1/0: > > [ 31.113988] #0: ((cpu_died).wait.lock){......}, at: [] complete+0x14/0x44 > > [ 31.114012] #1: (&p->pi_lock){-.-.-.}, at: [] try_to_wake_up+0x28/0x300 > > [ 31.114035] #2: (rcu_read_lock){......}, at: [] select_task_rq_fair+0x5c/0xa04 > > [ 31.114038] > > [ 31.114038] stack backtrace: > > [ 31.114046] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.19.0-rc7-next-20150203 #1914 > > [ 31.114050] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > [ 31.114076] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [ 31.114091] [] (show_stack) from [] (dump_stack+0x70/0xbc) > > [ 31.114105] [] (dump_stack) from [] (select_task_rq_fair+0x6e0/0xa04) > > [ 31.114118] [] (select_task_rq_fair) from [] (try_to_wake_up+0xd4/0x300) > > [ 31.114129] [] (try_to_wake_up) from [] (__wake_up_common+0x4c/0x80) > > [ 31.114140] [] (__wake_up_common) from [] (__wake_up_locked+0x14/0x1c) > > [ 31.114150] [] (__wake_up_locked) from [] (complete+0x34/0x44) > > [ 31.114167] [] (complete) from [] (cpu_die+0x24/0x84) > > [ 31.114179] [] (cpu_die) from [] (cpu_startup_entry+0x328/0x358) > > [ 31.114189] [] (cpu_startup_entry) from [<40008784>] (0x40008784) > > [ 31.114226] CPU1: shutdown > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > Would it be better to use IPIs instead? The IPI handler could even call > complete() as long as we IPI off the dying CPU to the killing CPU. I > suppose this could be an extension of the current IPI_COMPLETION that we > already have. That sounds good. I wonder where register_ipi_completion() should be put. This must execute before cpu_die() of dying CPU (if I get it right). So it cannot be __cpu_die(). One candidate is __cpu_disable() but it may not be called always. Any ideas? > > > arch/arm/kernel/smp.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 49 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c > > index 86ef244c5a24..bb8ff465975f 100644 > > --- a/arch/arm/kernel/smp.c > > +++ b/arch/arm/kernel/smp.c > > @@ -213,7 +219,40 @@ int __cpu_disable(void) > > return 0; > > } > > > > -static DECLARE_COMPLETION(cpu_died); > > +/* > > + * Wait for 5000*1 ms for 'wait_cpu_die' bit to be cleared. > > + * Actually the real wait time will be longer because of schedule() > > + * called bit_wait_timeout. > > + * > > + * Returns 0 if bit was cleared (CPU died) or non-zero > > + * otherwise (1 or negative ERRNO). > > + */ > > +static int wait_for_cpu_die(void) > > +{ > > + int retries = 5000, sleep_ms = 1, ret = 0; > > + > > + might_sleep(); > > + > > + smp_mb__before_atomic(); > > + while (test_bit(CPU_DIE_WAIT_BIT, &wait_cpu_die)) { > > + ret = out_of_line_wait_on_bit_timeout(&wait_cpu_die, > > + CPU_DIE_WAIT_BIT, bit_wait_timeout, > > + TASK_UNINTERRUPTIBLE, > > + msecs_to_jiffies(sleep_ms)); > > + if (!ret || (--retries <= 0)) > > + break; > > + > > + if (retries < 4000) { > > + /* After ~1000 ms increase sleeping time to 10 ms */ > > + retries = 400; > > + sleep_ms = 10; > > + } > > + > > + smp_mb__before_atomic(); /* For next test_bit() in loop */ > > + } > > + > > + return ret; > > +} > > > > Is there any reason we test the bit before testing it again in > out_of_line_wait_on_bit_timeout()? Why can't we just call that function > in a loop and let it handle checking the bit? I think there is no strong reason. Maybe except that if bit was cleared already then we skip the wait preparation steps. I followed the convention of wait_on_bit in include/linux/wait.h. I'll remove the test. > > > @@ -267,7 +312,8 @@ void __ref cpu_die(void) > > * this returns, power and/or clocks can be removed at any point > > * from this CPU and its cache by platform_cpu_kill(). > > */ > > - complete(&cpu_died); > > + clear_bit(CPU_DIE_WAIT_BIT, &wait_cpu_die); > > + smp_mb__after_atomic(); > > > > /* > > * Ensure that the cache lines associated with that completion are > > This comment here should be updated because the completion is gone. Yes, indeed. I'll update it. Thanks for feedback, Krzysztof