Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp59186ybj; Wed, 6 May 2020 11:30:53 -0700 (PDT) X-Google-Smtp-Source: APiQypI87BGmjay+JKorUEOI0yRz7Z4wVuYpAa7EgumDk74Yz6If+AQVX4cQrFI/lr8piP5xuU1C X-Received: by 2002:a17:906:90d0:: with SMTP id v16mr5257896ejw.114.1588789853394; Wed, 06 May 2020 11:30:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588789853; cv=none; d=google.com; s=arc-20160816; b=GmiZgaAQt5WErMMlEIDZ/jSK4KWwn0Ifm94eM9XmrhQq7mNbPr50v6gyo6WkWJKEby 3pMFFGouq/IhhCipvWfMEkZ/7Q5unTKJflaOXoiKZXooCbBnxU4A8CoCBxR4DNfwhyqH XRXueRj/iSaj36v+szJZpaVGsh8OLL4t3bcOKmFWdt/fx+9Np0HA6x7RLGQIYrdUNGzG PrHV6psJToyjSwLYipTgrc1N4FOlpw2RgoY+za/0SvTj+TU1iBrW3a7sNWUEWFpe3JBG CojqQM45czsHhHMaXxKmc+LToTS4CWQt+aA/grVPdlhN2Hj6oJX5aPsCuSIMAfqNC8SL EgrA== 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:reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=oFhn5zVvgGrAUPMLI8VcAq9bQnhXNd17VobOGdbk3mY=; b=fFZyOL4XmVrUorcigkyylXDUAofJFx9DbLFMBPh/mWdgA2/mjXxsGB7CGlG6HbU5R0 AskeUkOYEEoeC95JgLidgdsizILUJFEzX5GnNZa1XBxe5/R/+kvQ/2HUXX9PGPCtpyys E+m540vTHnvwbZ4sALdZUrK8skThtb+9rmyayg83rKICR9NhGIdXgATjxQhaF4fvL7wj 4XAuqx3s+jUjhUTXchS0IXxdr7vS86i+06Z2P0oONJXpCyw/tW/NgnMCuxyPEm4LqyTK 578Z08z1Rlnp+D4q++HpuxUdpeuIBJe9O1hzhlkKkt6dEFh5tIhj0Ktjf7Pde0/lnaKd crmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qo8WuAbK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u19si1141042edi.518.2020.05.06.11.30.27; Wed, 06 May 2020 11:30:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qo8WuAbK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730037AbgEFS25 (ORCPT + 99 others); Wed, 6 May 2020 14:28:57 -0400 Received: from mail.kernel.org ([198.145.29.99]:34028 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729313AbgEFS25 (ORCPT ); Wed, 6 May 2020 14:28:57 -0400 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 20EE020708; Wed, 6 May 2020 18:28:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588789736; bh=wZc8GE0Iy2gyxMgpOHL9RTIZW0KwAwAYkEbYTQG3M24=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=qo8WuAbK9clfsd5xkAs+kEy2nfWEE+FJejg+4kv4+p05N4aCxt0M8Td/qebmw6Ti7 a69avL7vupXS4pJtza7UeVXQmhYPsMUFdGyy3AdRDFCGBcPjbRNadkSM5nfq0OzvXh EXedyliq9dadDN/WzVIbqhnZwzYg/KgsNZCXzJVY= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 09D92352306C; Wed, 6 May 2020 11:28:56 -0700 (PDT) Date: Wed, 6 May 2020 11:28:56 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Alexandre Chartre , Thomas Gleixner , LKML , x86@kernel.org, Andy Lutomirski , Frederic Weisbecker , Paolo Bonzini , Sean Christopherson , Masami Hiramatsu , Petr Mladek , Steven Rostedt , Joel Fernandes , Boris Ostrovsky , Juergen Gross , Brian Gerst , Mathieu Desnoyers , Josh Poimboeuf , Will Deacon Subject: Re: [patch V4 part 1 03/36] sched: Clean up scheduler_ipi() Message-ID: <20200506182856.GD2869@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200505131602.633487962@linutronix.de> <20200505134058.361859938@linutronix.de> <20200506153300.GB5281@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200506153300.GB5281@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 06, 2020 at 05:33:00PM +0200, Peter Zijlstra wrote: > On Wed, May 06, 2020 at 02:37:19PM +0200, Alexandre Chartre wrote: > > On 5/5/20 3:16 PM, Thomas Gleixner wrote: > > > @@ -650,6 +655,16 @@ static inline bool got_nohz_idle_kick(vo > > > return false; > > > } > > > +static void nohz_csd_func(void *info) > > > +{ > > > + struct rq *rq = info; > > > + > > > + if (got_nohz_idle_kick()) { > > > + rq->idle_balance = 1; > > > + raise_softirq_irqoff(SCHED_SOFTIRQ); > > > + } > > > +} > > > + > > > #else /* CONFIG_NO_HZ_COMMON */ > > > static inline bool got_nohz_idle_kick(void) > > > > #ifdef CONFIG_NO_HZ_COMMON > > > rq->last_blocked_load_update_tick = jiffies; > > > atomic_set(&rq->nohz_flags, 0); > > > + > > > + rq_csd_init(rq, &rq->nohz_csd, nohz_csd_func); > > > #endif > > > #endif /* CONFIG_SMP */ > > > hrtick_rq_init(rq); > > > --- a/kernel/sched/fair.c > > > +++ b/kernel/sched/fair.c > > > @@ -10009,12 +10009,11 @@ static void kick_ilb(unsigned int flags) > > > return; > > > /* > > > - * Use smp_send_reschedule() instead of resched_cpu(). > > > - * This way we generate a sched IPI on the target CPU which > > > + * This way we generate an IPI on the target CPU which > > > * is idle. And the softirq performing nohz idle load balance > > > * will be run before returning from the IPI. > > > */ > > > - smp_send_reschedule(ilb_cpu); > > > + smp_call_function_single_async(ilb_cpu, &cpu_rq(ilb_cpu)->wake_csd); > > > > This should be nohz_csd instead of wake_csd, no? I.e.: > > > > smp_call_function_single_async(ilb_cpu, &cpu_rq(ilb_cpu)->nohz_csd); > > You figured correctly. Thanks! And this does get rid of the smp_call_function splats I was seeing earlier, thank you! I still see warnings of the form "leave instruction with modified stack frame" from older complilers and of the form "undefined stack state" from newer compilers. I am running stock objtool versions, so I am guessing that this is at least one reason for these warnings. Thanx, Paul