Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2418464yba; Sun, 28 Apr 2019 00:03:25 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRcTjyNmFdshkuL2E3dvApqxgK8g+WM0G0Vo9iW+LgN+r3trobypZKkIkYH6aLHppPikv+ X-Received: by 2002:a65:5089:: with SMTP id r9mr52328401pgp.14.1556435005860; Sun, 28 Apr 2019 00:03:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556435005; cv=none; d=google.com; s=arc-20160816; b=jvNm39kAkjEAfO1EqzMAzw+Axqhio58ct/U5C2GDfRby7kIBVwPdeh9SNID6FNtSUi WzlvouRLqnQlrZPknHGkr1INBbosewjbZIhRmieXpIGDA2bGDz4RABXbIZfL4I/uNQcA C3A1zyWYhpsST77wFuzC62j9hDMp8obvlpNokNILWKJrBnk+prMYJuut3ZXArXApr2oy RFRU3rB89HgWkOGPI7ISk510iQpjTWVZQf9/dYiklud36RTHCNMK3wVQ7u5gbB7ulNBb IVdtNDCJfMz/YoBH46GYvEjf0Xbuy0a5DGGZ7omKGLvHG7CX1sXgFl4DH7wzCgnwLEYl Ha0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=jmImGZtkfnl+9FwSUFUpPhx23vdpYvm27KSz2RV8xh8=; b=O5vUPj3cVBT9lWRuXw656sBFL9oeSsGmfAtDXYeU/ub9CYfVZfABEa423ogmVFrBZc dPNYFwu9W+zkS8GuwncJRK7mbfH6YU1AloWBsDuQKRuDipIRNceLXxqEhBQh9nSC4rxL qnxQY68aeMn5aP9/kfrTYQMHxuJ0zHbiJYlXkhL8gpCzbXIqYp09wmxHrO6R8taR7f1R g8ypDjwyPsZ4pNtdCZ7BecLtBZ7SGOVEDu8c4eP+VBmv40jf0voPl1tSPMkpDWS/qHIm KbuCEu9Px2jL6fIi6G85wfdlngwj0AQX8bKCWAh8anZteq9leSq7z2vn0HFkE9Jr6f7w w/4A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tezBQwkG; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 1si19976925pln.91.2019.04.28.00.03.09; Sun, 28 Apr 2019 00:03:25 -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=pass header.i=@gmail.com header.s=20161025 header.b=tezBQwkG; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726479AbfD1HBE (ORCPT + 99 others); Sun, 28 Apr 2019 03:01:04 -0400 Received: from mail-oi1-f196.google.com ([209.85.167.196]:41899 "EHLO mail-oi1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726133AbfD1HBD (ORCPT ); Sun, 28 Apr 2019 03:01:03 -0400 Received: by mail-oi1-f196.google.com with SMTP id v23so5901029oif.8 for ; Sun, 28 Apr 2019 00:01:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jmImGZtkfnl+9FwSUFUpPhx23vdpYvm27KSz2RV8xh8=; b=tezBQwkG958wl9qV6VPis1TYiM1DCy5YhiJ78oksmp6EcTCzjlIIozspHQfXkW3tLj ObDJREHDH9G4c8naro80jAFDRqfE+KVBOjsnhc+h1tJsiNtueCJY6Mc/akTKHjH//FsS EqWn+fPp/31zRP8+1Hy3Y0NAm9HNL/C9+EGl1OuHTcLkzFASbxwbRGy9u1WXA36Dv55t 6wikCf+mmzH1msOGZay5D6ksJKucOxJ04GfwHrts9n26yuAeDtoQY6czS1ZsupZgS6fZ 1mPeJ0fsf/DkO9SaE6YvYdHpumCLUqlsCpo30+lz9iwlLyWaGgbPeh8tdNLFvC07onmv /HNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jmImGZtkfnl+9FwSUFUpPhx23vdpYvm27KSz2RV8xh8=; b=q8oK9bYmhLUK9jDTmpIqGCe/0Q4MgV96miSr8VYWci2qD/3M/JsfdZgUkrXajkzo1M 2JbGqKueGyE6J3v6JgmZvbUSmt8iX77bPb1mA49WajX7+Ed1wmIqAzchdvrgS4dBUBNa j9VqNnIYRfl5ihh/8zMc4/325fILCXBrObZEnzkPXHA0h8SEzYsZHaL0sulMlBOBgAUB o124b47RjK1sMt5p4O5I3SzBVvsmR27VpP+0/EYD0Q7s4ZCIQA4ae+8AJps2Md6RglZV ++fZJIP5RBF9K4IQ9I6O++xq3w8yUtx65oiPdYwicrkX3RxZUwmoaVP8MsPKwgMQHvdy xaZA== X-Gm-Message-State: APjAAAXGJUHSxorsf0IB8K4GAn6muDtri03+mXCVXOMY+T7KiTziL3UI 1f73uYeZ/fT3bn3mtweajAGdFfZEbGPAuqx01Zw= X-Received: by 2002:aca:4942:: with SMTP id w63mr3208606oia.33.1556434863080; Sun, 28 Apr 2019 00:01:03 -0700 (PDT) MIME-Version: 1.0 References: <20190412042613.28930-1-npiggin@gmail.com> In-Reply-To: <20190412042613.28930-1-npiggin@gmail.com> From: Wanpeng Li Date: Sun, 28 Apr 2019 15:01:18 +0800 Message-ID: Subject: Re: [PATCH] kernel/sched: run nohz idle load balancer on HK_FLAG_MISC CPUs To: Nicholas Piggin Cc: Thomas Gleixner , Frederic Weisbecker , Ingo Molnar , Peter Zijlstra , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 Apr 2019 at 12:27, Nicholas Piggin wrote: > > The nohz idle balancer runs on the lowest idle CPU. This can > interfere with isolated CPUs, so confine it to HK_FLAG_MISC > housekeeping CPUs. > > HK_FLAG_SCHED is not used for this because it is not set anywhere > at the moment. This could be folded into HK_FLAG_SCHED once that > option is fixed. > > The problem was observed with increased jitter on an application > running on CPU0, caused by nohz idle load balancing being run on > CPU1 (an SMT sibling). > > Signed-off-by: Nicholas Piggin > --- > kernel/sched/fair.c | 16 ++++++++++------ > 1 file changed, 10 insertions(+), 6 deletions(-) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index fdab7eb6f351..d29ca323214d 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -9522,22 +9522,26 @@ static inline int on_null_domain(struct rq *rq) > * - When one of the busy CPUs notice that there may be an idle rebalancing > * needed, they will kick the idle load balancer, which then does idle > * load balancing for all the idle CPUs. > + * - HK_FLAG_MISC CPUs are used for this task, because HK_FLAG_SCHED not set > + * anywhere yet. > */ > > static inline int find_new_ilb(void) > { > - int ilb = cpumask_first(nohz.idle_cpus_mask); > + int ilb; > > - if (ilb < nr_cpu_ids && idle_cpu(ilb)) > - return ilb; > + for_each_cpu_and(ilb, nohz.idle_cpus_mask, > + housekeeping_cpumask(HK_FLAG_MISC)) { > + if (idle_cpu(ilb)) > + return ilb; > + } What will happen if cpu1 is still idle currently && housekeeping? Regards, Wanpeng Li > > return nr_cpu_ids; > } > > /* > - * Kick a CPU to do the nohz balancing, if it is time for it. We pick the > - * nohz_load_balancer CPU (if there is one) otherwise fallback to any idle > - * CPU (if there is one). > + * Kick a CPU to do the nohz balancing, if it is time for it. We pick any > + * idle CPU in the HK_FLAG_MISC housekeeping set (if there is one). > */ > static void kick_ilb(unsigned int flags) > { > -- > 2.20.1 >