Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp375430pxj; Fri, 7 May 2021 10:29:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGEn6yhJwml/PevpBX5yImR5jRWBVZA1I/ckQNFMi9yS1U8S2pc3lsoJgkIoS/+jCFSkl1 X-Received: by 2002:a17:90a:be10:: with SMTP id a16mr23010039pjs.112.1620408555913; Fri, 07 May 2021 10:29:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620408555; cv=none; d=google.com; s=arc-20160816; b=A6jAKrnoDVpR7JXfsCKUmyp/M4vqfDt20uKyAxG9XXwgk7uHWbWoWd9c5sx9tkguqr F0txyZelHu3HaTK7VU/XTm5V2oHXPbbMyMP+QPSuNcI1tQRwTqRywnWf3O5zlC8RAT+d XtG5RagNVXgXoJ/CNNcn84+IAEZMjX7KsG2qZWNKNVK7DQKvhOpLeDTEv1fIrnn6KJz7 IE7pXBo2dlZoxICBL6lSRLql/vw7DA9bADw9oS4/3w4XCch71Qhx2IhUd7aQs/qSCo+u XUQrl+Oh95KPyBvrxtJOwuZkMwnkIdK/rTkR1nwjZmBKfsvb/5pBBUVESeq4oxj4lptm kgDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=dy+3jxRB9L0wuk4SMujlban9APxZ3gqvsFv5w04n7Xg=; b=VwQYI/SjHbd94qlT0+91fuUPZsWWmeOO37FBUq2GVAOrGu11dWCYO4JSmHnQpoyHHs 16TmUahXQ/XeBem9cPbsfAugD39P069A7+tYH7xvkRIlwfM8mUYjjE+1v5QcRGAkW3e5 J9jQ8YS93jIPvhVwokVuUxfpuGGYNAitBvGyoA8wqIuG9ssmeb+0kJmRk1AZvgVUFwSt ePZgyHABXqh7SvLDmddia/T01HtctsMuWFadN5iZpzPjy6XqUuJ/ElFXL7BHDVKCDvGH frrYql14MZ1biqvfkBqKqFjHqpltylNIs7i0h2JgCM933M5kE/avz4wCHrb3H8xbHXSX H9SA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z7si7526487pfz.153.2021.05.07.10.29.03; Fri, 07 May 2021 10:29:15 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234897AbhEGPUP (ORCPT + 99 others); Fri, 7 May 2021 11:20:15 -0400 Received: from foss.arm.com ([217.140.110.172]:33882 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230453AbhEGPUM (ORCPT ); Fri, 7 May 2021 11:20:12 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6D3B611B3; Fri, 7 May 2021 08:19:11 -0700 (PDT) Received: from e113632-lin (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE0E63F73B; Fri, 7 May 2021 08:19:09 -0700 (PDT) From: Valentin Schneider To: Vincent Guittot , Scott Wood Cc: Ingo Molnar , Peter Zijlstra , Dietmar Eggemann , Steven Rostedt , Mel Gorman , linux-kernel , linux-rt-users , Sebastian Andrzej Siewior , Thomas Gleixner Subject: Re: [PATCH v2 1/3] sched/fair: Call newidle_balance() from balance_callback on PREEMPT_RT In-Reply-To: References: <20210428232821.2506201-1-swood@redhat.com> <20210428232821.2506201-2-swood@redhat.com> Date: Fri, 07 May 2021 16:19:07 +0100 Message-ID: <87v97uinbo.mognet@arm.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/05/21 14:13, Vincent Guittot wrote: > On Thu, 29 Apr 2021 at 01:28, Scott Wood wrote: >> >> This is required in order to be able to enable interrupts in the next >> patch. This is limited to PREEMPT_RT to avoid adding potentially >> measurable overhead to the non-RT case (requiring a double switch when >> pulling a task onto a newly idle cpu). > > IIUC, only the newidle_balance is a problem and not the idle load > balance that runs softirq. In this case, why not skipping > newidle_balance entirely in case of preempt_rt and kick an idle load > balance instead as you switch to idle thread context anyway > So if I follow you, that would be along the lines of having PREEMPT_RT turn newidle_balance() into: rq->idle_balance = CPU_IDLE; rq->next_balance = jiffies; trigger_load_balance(rq); which I'm thinking isn't too crazy.