From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752916AbdCHPgt (ORCPT ); Wed, 8 Mar 2017 10:36:49 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36752 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753396AbdCHPgq (ORCPT ); Wed, 8 Mar 2017 10:36:46 -0500 MIME-Version: 1.0 In-Reply-To: References: <1486543409-11493-1-git-send-email-urezki@gmail.com> <1486543409-11493-3-git-send-email-urezki@gmail.com> <20170209122218.GE6500@twins.programming.kicks-ass.net> <20170213135149.GQ6515@twins.programming.kicks-ass.net> <1f0bc6a4-7e17-98bf-2ef0-a805e32a5591@arm.com> From: Uladzislau Rezki Date: Wed, 8 Mar 2017 16:35:42 +0100 Message-ID: Subject: Re: [RFC,v2 3/3] sched: ignore task_h_load for CPU_NEWLY_IDLE To: Peter Zijlstra Cc: Ingo Molnar , LKML , Uladzislau 2 Rezki , Oleksiy Avramchenko , Dietmar Eggemann Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello. Let's decide how to proceed with https://lkml.org/lkml/2017/2/14/334 patch. Despite it is not a big change, i think it is important and ready to be submited, unless there are still any comments. -- Uladzislau Rezki On Thu, Feb 16, 2017 at 12:20 PM, Uladzislau Rezki wrote: > On Wed, Feb 15, 2017 at 7:58 PM, Dietmar Eggemann > wrote: >> On 02/14/2017 06:28 PM, Uladzislau Rezki wrote: >>>>> >>>>> >>>>> So that is useful information that should have been in the Changelog. >>>>> >>>>> OK, can you respin this patch with adjusted Changelog and taking Mike's >>>>> feedback? >>>>> >>>> Yes, i will prepare a patch accordingly, no problem. >>>> >>>>> >>>>> Also, I worry about the effects of this on !PREEMPT kernels, the first >>>>> hunk (which explicitly states is about latency) should be under >>>>> CONFIG_PREEMPT to match the similar case we already have in >>>>> detach_tasks(). >> >> >> This one uses #ifdef CONFIG_PREEMPT whereas you use >> IS_ENABLED(CONFIG_PREEMPT). Is there a particular reason for this? >> > I just wanted to put it under one line instead of using #ifdefs in my > second hunk, > so that is a matter of taste. Also, please find below different > variants of how it can be > rewriten: > > > #ifdef CONFIG_PREEMPT > if (env->idle != CPU_NEWLY_IDLE) > #endif > if ((load / 2) > env->imbalance) > goto next; > > > > #ifdef CONFIG_PREEMPT > if (env->idle != CPU_NEWLY_IDLE && > (load / 2) > env->imbalance) > goto next; > #else > if ((load / 2) > env->imbalance) > goto next; > #endif > > > If somebody has any preferences or concerns, please comment, i will > re-spin the patch. > > -- > Uladzislau Rezki