From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6254DC43334 for ; Fri, 24 Jun 2022 12:18:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230410AbiFXMSo (ORCPT ); Fri, 24 Jun 2022 08:18:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbiFXMSm (ORCPT ); Fri, 24 Jun 2022 08:18:42 -0400 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A79910547 for ; Fri, 24 Jun 2022 05:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656073121; x=1687609121; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=517H1yHK+nS4fYXm61DYKdd+jOnnRIOAzK1KRZWOQGA=; b=E+g5uVb8aXWRawUxyY+D8VKXqdWuB/Hfp05fs4SCYilSSjnmgmX8Q5vy jcj0dDt027MJ0pAvmyVKB8W+BiEa8+SgV3hCt/Y8ep9RDZ0ltdl8c2RA4 Y5tcuSMBEcBqs9csU0OpwFccBJwClxYdh8pwzpx5eXQfM9/y6Zu1rxt09 eTcEe66saxk0cEBDJPcYGUsqSrDzpnktLwan0Hd9ZFDqDMWg7bZGa6Oaa jOR/h7/kOiLjPv3ySJ75zv8qyI6UyXUiJk7Asyh1w/bxfjMrDiaw0uzyt 2VzbQIJ/7m51e7g63Tvo/5/vcA7rG+33APY7GQZnVzidUE7s+XZ5RI3eR w==; X-IronPort-AV: E=McAfee;i="6400,9594,10387"; a="281032213" X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="281032213" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 05:18:41 -0700 X-IronPort-AV: E=Sophos;i="5.92,218,1650956400"; d="scan'208";a="645250458" Received: from cma16-mobl1.ccr.corp.intel.com (HELO chenyu5-mobl1) ([10.255.29.162]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2022 05:18:35 -0700 Date: Fri, 24 Jun 2022 20:18:31 +0800 From: Chen Yu To: Peter Zijlstra Cc: K Prateek Nayak , Vincent Guittot , Mel Gorman , Ingo Molnar , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Barry Song <21cnbao@gmail.com>, Srikar Dronamraju , Len Brown , Ben Segall , Aubrey Li , Abel Wu , Daniel Bristot de Oliveira , Tim Chen , linux-kernel@vger.kernel.org, Yicong Yang , Mohini Narkhede Subject: Re: [PATCH v4] sched/fair: Introduce SIS_UTIL to search idle CPU based on sum of util_avg Message-ID: <20220624121831.GA5570@chenyu5-mobl1> References: <20220612163428.849378-1-yu.c.chen@intel.com> <76c94a3b-6ca2-e0e2-c618-42b147d2737d@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 24, 2022 at 09:29:58AM +0200, Peter Zijlstra wrote: > On Wed, Jun 22, 2022 at 12:06:55PM +0530, K Prateek Nayak wrote: > > Hello Chenyu, > > > > I'm sorry for the delay. The testing took a while but below are > > the results from testing on our system. > > > > tl;dr > > > > o We ran all the tests with with SIS_PROP disabled. > > o tbench reaches close to saturation early with 256 clients. > > o schbench shows improvements for low worker counts. > > o All other benchmark results seem comparable to tip. > > We don't see any serious regressions with v4. > > > > > @@ -61,6 +61,7 @@ SCHED_FEAT(TTWU_QUEUE, true) > > > * When doing wakeups, attempt to limit superfluous scans of the LLC domain. > > > */ > > > SCHED_FEAT(SIS_PROP, true) > > > > SIS_PROP was disabled in our testing as follows: > > > > -- > > -SCHED_FEAT(SIS_PROP, true) > > +SCHED_FEAT(SIS_PROP, false) > > So how about I make this change. > > > With v4 on the current tip, I don't see any need for > > a special case for systems with smaller LLCs with > > SIS_PROP disabled and SIS_UITL enable. Even SIS Efficiency > > seems to be better with SIS_UTIL for hackbench. > > > > Tested-by: K Prateek Nayak > > And apply this thing, lets see how it fares.. OK, thanks, Peter. Best, Chenyu