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 B550FECAAD8 for ; Fri, 16 Sep 2022 11:48:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230495AbiIPLsW (ORCPT ); Fri, 16 Sep 2022 07:48:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230496AbiIPLsQ (ORCPT ); Fri, 16 Sep 2022 07:48:16 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8D3BACA32 for ; Fri, 16 Sep 2022 04:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=jRLLoms3gEFmE3Xqk3ace4Mb+kdij3/aL1dHcL5UlLY=; b=Aokz8rIoFPHEGU/NeMtgjaI7yE lUegGiRNvJbrPBr3jicrciiVj7SPmG5E9s43CoWSv0shwTZ3k80xR+CaCAJdUNt8Y/KiCAlpyoINr 2WmnfdfV4F15nGURh3CLrncu2dPw42nmEGezlLI9xun4cgtrtWYzg7CdSDfBzaVAC0akfwNFhYILk Lxcj1BpKKImKvSHI/xRO2MgMz+G1MOILvqQr7vuqNIXjUj94tqizlvoBhnvnIAKRFaaOjbGCRBKM4 3pX77kvwX4/3ldkOQNbLgYDZ3IhZNucpb4yxSjdL6zNnPTbYTH7/ofQGkFtPK4MqiVc27xNMyGHLm AkeeQehQ==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1oZ9oz-00CzGj-T0; Fri, 16 Sep 2022 11:47:50 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 7E8F430013F; Fri, 16 Sep 2022 13:47:49 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 656BC201A0BBA; Fri, 16 Sep 2022 13:47:49 +0200 (CEST) Date: Fri, 16 Sep 2022 13:47:49 +0200 From: Peter Zijlstra To: Chen Yu Cc: Vincent Guittot , Tim Chen , Mel Gorman , Juri Lelli , Rik van Riel , Aaron Lu , Abel Wu , K Prateek Nayak , Yicong Yang , "Gautham R . Shenoy" , Ingo Molnar , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] sched/fair: Choose the CPU where short task is running during wake up Message-ID: References: <20220915165407.1776363-1-yu.c.chen@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220915165407.1776363-1-yu.c.chen@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 16, 2022 at 12:54:07AM +0800, Chen Yu wrote: > Current proposal is a variant of 2: > If the target CPU is running a short-time slice task, and the wakee > is also a short-time slice task, the target CPU could be chosen as the > candidate when the system is busy. Since this benchmark only has short running tasks, the result is that you always pick the local cpu and therefore the migrations are reduced? Doesn't this inhibit spreading the workload when there's geniunely idle CPUs around?