Received: by 10.192.165.148 with SMTP id m20csp360662imm; Wed, 2 May 2018 01:21:02 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo4O1i+qjtY6YxZZvkobKIPmWPHgEodBlBM+uznIM9K6SJnTDOJKOXsZNvwtdPG6CmI/c+M X-Received: by 2002:a63:7d47:: with SMTP id m7-v6mr8749136pgn.443.1525249262080; Wed, 02 May 2018 01:21:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525249262; cv=none; d=google.com; s=arc-20160816; b=qEicHQgd75kk+vijdJjk5TSsPYHRdD5mHoEGrF0ltc++iBzU+04q/OOcOgYgpwS0Uj nY2QMZkyqZqzYY1tWbJNs3bTiQ6nLw4skVMbgTdpd2GqWcvDnXzqTw4DqTcrFAGZV2+S y8TnlB5LREzMVIuse5UaSoRhTHncx/NzkWf7BOtEwpwmrJfJRyjfS0LAfksXw/OoqG2H YU587dWzvsj1kwek90F2NvcuiEz0TmapkclBY/jGmXtANHtl8jXK9T3kPoTCMHWNUQ0+ o2zhS5+ooVlfPgxoGMVm+gHQiQAqqSzTkKSUDNssWXVhkRP/2GDTriQhXTZFiGzi7y3h epEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=2ZGvUKALNGHNfR+C1e+1Zcj1wQghq76OqWwVHaTmF9s=; b=EY4uSFsO3tTKA3MpIshy/Nti2hNip/grgzWVzMsrUZhnzumD241MjxvuPy9YjwE3Ya l2jigNMb4I970GZ533xiDkzm4GXKevM9DlLtyIex/ogOGWLQ/ct0DgUX2gOCiBfJ2Xi+ 5pL72sT18mD5xtUANzZNy+OIQdxAVzTc+4RqaI57x1JNjqGKhLTQ3JSmGSai6orUB/f2 qUH1LB4uDR0XVmw7SMJ9ShteKN5ksbl/7AksDR4tXpSIh/3Ds4m+WhL7RnIwRGjCaIaD Zrets1BZKed5+tYgT6fCbNAjCmTT5GdBSkIwZ6/sOTOSLt11c/EcdaREx+s6an231Ur/ Ancg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=i910qbPU; 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 i67si11110825pfi.95.2018.05.02.01.20.47; Wed, 02 May 2018 01:21:02 -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; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=i910qbPU; 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 S1751393AbeEBIUa (ORCPT + 99 others); Wed, 2 May 2018 04:20:30 -0400 Received: from merlin.infradead.org ([205.233.59.134]:52796 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751116AbeEBIU1 (ORCPT ); Wed, 2 May 2018 04:20:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2ZGvUKALNGHNfR+C1e+1Zcj1wQghq76OqWwVHaTmF9s=; b=i910qbPU6hPdYCPpSLoMk3JDR /GglhRzlmc3ZneBXrs/QUQNJ9nga4U8N5lrlTqMOrsKMUpcmxf5gVJaCtmaiuWQDjMtpPzrngJAOM 01C2CaVTjaETp2+bGp0uAs9VkAiyjwr5dtTFiZEK3HIA2omtJ7Eqr4n69M8n3RSkreId+IanrDLQk vxLKv6GxeWx6c2NllxFSlvhaKV5Riods4/nhpiJ8s4DILLjQt4ulNwa3VNICONBU4y+zwDnZQ23gW hABw4NT79J3moih8riXge/xByzFRPqOaBlD9acYgYqb/12YsN8vHNrVGhG/lSIJGy0HDM3YfbD+c4 da7Grmbrg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fDmzm-0007fj-Hc; Wed, 02 May 2018 08:20:14 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 6325F2029FA14; Wed, 2 May 2018 10:20:11 +0200 (CEST) Date: Wed, 2 May 2018 10:20:11 +0200 From: Peter Zijlstra To: "Kohli, Gaurav" Cc: tglx@linutronix.de, mpe@ellerman.id.au, mingo@kernel.org, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Neeraj Upadhyay , Will Deacon , Oleg Nesterov Subject: Re: [PATCH v1] kthread/smpboot: Serialize kthread parking against wakeup Message-ID: <20180502082011.GB12180@hirez.programming.kicks-ass.net> References: <20180426085719.GW4129@hirez.programming.kicks-ass.net> <4d3f68f8-e599-6b27-a2e8-9e96b401d57a@codeaurora.org> <20180430111744.GE4082@hirez.programming.kicks-ass.net> <3af3365b-4e3f-e388-8e90-45a3bd4120fd@codeaurora.org> <20180501101845.GE12217@hirez.programming.kicks-ass.net> <20180501113132.GF12217@hirez.programming.kicks-ass.net> <745d762d-9ab3-0749-9b87-9bb03d913071@codeaurora.org> <20180501131904.GG12217@hirez.programming.kicks-ass.net> <9b289790-9b3a-73bd-7166-bf39f32cefd8@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9b289790-9b3a-73bd-7166-bf39f32cefd8@codeaurora.org> User-Agent: Mutt/1.9.5 (2018-04-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 02, 2018 at 10:45:52AM +0530, Kohli, Gaurav wrote: > On 5/1/2018 6:49 PM, Peter Zijlstra wrote: > > - complete(&kthread->parked), which we can do inside schedule(); this > > solves the problem because then kthread_park() will not return early > > and the task really is blocked. > > I think complete will not help, as problem is like below : > > Control Thread CPUHP thread > > cpuhp_thread_fun > Wake control thread > complete(&st->done); > > takedown_cpu > kthread_park > set_bit(KTHREAD_SHOULD_PARK > > Here cpuhp is looping, > //success case > Generally when issue is not > coming > it schedule out by below : > ht->thread_should_run(td->cpu > scheduler > //failure case > before schedule > loop check > (kthread_should_park() > enter here as PARKED set > > wake_up_process(k) If k has TASK_PARKED, then wake_up_process() which uses TASK_NORMAL will no-op, because: TASK_PARKED & TASK_NORMAL == 0 > __kthread_parkme > complete(&self->parked); > SETS RUNNING > schedule But suppose, you do get that store, and we get to schedule with TASK_RUNNING, then schedule will no-op and we'll go around the loop and not complete. See also: lkml.kernel.org/r/20180430111744.GE4082@hirez.programming.kicks-ass.net Either TASK_RUNNING gets set before we do schedule() and we go around again, re-set TASK_PARKED, resched the condition and re-call schedule(), or we schedule() first and ttwu() will not issue the TASK_RUNNING store. In either case, we'll eventually hit schedule() with TASK_PARKED. Then, and only then will the complete() happen. > wait_for_completion(&kthread->parked); The point is, we'll only ever complete ^ that completion when we've scheduled out the task in TASK_PARKED state. If the task didn't get parked, no completion. And that is the reason I like this approach above the others. It guarantees the task really is parked when we ask for it. We don't have to deal with the task still running and getting migrated to another CPU nonsense.