From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA6DC1F1309 for ; Wed, 8 Jan 2025 10:47:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736333279; cv=none; b=ur31nQhJNktlb/b8FbLws3lalTKqhlWKKSWMMiKl6cOV+rI8pedj1lud8yeJVhN3UIofV0r3mttRLVwK0fHac44OZ7pY5ExNw+D0OYG9rsqRctXJ/QJcOAQ0/D9E+alFFe//knQ7PWLBKdaZGHtQa0gh9nTNA0cTdzC0iE3j3JE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736333279; c=relaxed/simple; bh=Tu0RnQt/Y7AbRA1bhHAsTqMt/aQo547bTvpTSGk7BEY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bW9i8Aw04jUXLj0OL2i0ELXnAy84fTkXsJ044T0YnqZChzHXvMPeHn8ipmQ+0Bu0X5z7Z7DhRz1Iu/fib+dU9dSu6gtrC2vpIppWvTR655919CT6QW6g+7z4jnDeNcYMhzfpL2waSS5gkHbLlRwzRY3lbZumwmgF8G+KMABXJoQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=VuwdnPq9; arc=none smtp.client-ip=209.85.216.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="VuwdnPq9" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2ef72924e53so24415826a91.3 for ; Wed, 08 Jan 2025 02:47:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1736333277; x=1736938077; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=VfPKHPMYgMtzFWL6mqJB+KDy1OVZIPQBtmzhuaw2mow=; b=VuwdnPq9IW4dHTRr5kbSlshlpjl8ttvF2tl12sU3y6pqsSZB/0bujLIju54FTqytx+ KCPjcmJ/VQCq15o4LLrn8/QKBBoBs1a7Sx2wHxGiLiUO1grbMnUzucsb/uXhrYbNhLXp 7Ng4bq+G6J13iKSRSbxPEDsa8QWu4iKU8xbtdb6wx6pJ644G6eX2eCe1VnquTso5GF33 8DKLOdKcy0MJiH0I9Imh3FW0L5qbZuzuCg4RcxcbU2GfMQZCdSvYK8ZAEnuu3tPOrYGt LwMdKXuTjsYzQEz22p4KjrIEJOEUEY54mLQhrh4BxSWTwbm2/RFsDZuK1rVRTQr+cfhZ M8YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736333277; x=1736938077; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=VfPKHPMYgMtzFWL6mqJB+KDy1OVZIPQBtmzhuaw2mow=; b=xBo8eUEeQ7QG+GV+LOsGbPwDmmYTwuStVUeyL7oZkfNFdh6EIsudjo/eVgJv9OdnDO F2eEjijiyitthEfnrFWeaq+hOUkpDjMHUB+n1ljP0S0DSaJZ/NJn4dr5CweQf/VppuzB urG07bFTBdVP+V8bTlz+J+4q3IUKl4ro+VGnconb60UsYghnbQ3I3uxwGnqZYgHj6Huf 60v1RESm35fQdX/B6GyA7JgZLJRGnxmsItTuO7gZAAV0SHyrFPHvd+MZZ3/vLKN/yGxC ra/p/UFfOWn/Rs+OL3D++LJzC558120vA2agwQxKf/GD0pXi/qnqa9lUHOzZqKapWoYN S2CA== X-Forwarded-Encrypted: i=1; AJvYcCXRSE5IAwD/uyb+3edX93R9OBoakcdN0+YvfTD9fPHj0YKZasb1Yrt7TwmhxnYLNSEJ4UCe7OIJ48ICcPQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyO0LFaG/6W5f4ZnvNOEblbmpBwIcQzgVKLMr85Pt/Yc2oJL0Qp nn9+RZHD3gQJ7OOd9G5M3G8wWBIYvChrhT9oRog0Jagq0v1SCgKsbUvZ9NozVAE= X-Gm-Gg: ASbGncuJ5brGNhGseAfeZ+6ILmzOvxrfBHlQtTUVlSyrSe1Jhir5veJ/GPGx0KQ32e8 EAf6m4GhdQuB+FWibDO2aFDzr1WK32lr+FaPPKxYHygZ+UGPnNLGtRKR9fbg6Nes1PJWLGNC5Lz uCySfxIW4ChiBI/eeDXQhjzcZ5dYFtTE2keVWN7hRnH3JZzz8OioCcXakA7Pa6fd50jkGuIJZF1 CycqoSRL2LZM6OUqJhe8mlYS0IvGp2hJ/9SUbsqiA58zaUKtS+azEbEpmfkEsRIHTxe/qCzBeUx 8ldjJJE= X-Google-Smtp-Source: AGHT+IEBCUl2Ns4YKAESmedvqv9tr5KzSgofPlnhx/iY1UPnZr2Lf9pkjSL7fy1kkAY1pwusB7tlkw== X-Received: by 2002:a17:90b:2544:b0:2ee:c9b6:c267 with SMTP id 98e67ed59e1d1-2f548eaea9emr3658310a91.9.1736333277128; Wed, 08 Jan 2025 02:47:57 -0800 (PST) Received: from [10.254.21.45] ([139.177.225.231]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2f54a36a5a2sm1273119a91.50.2025.01.08.02.47.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2025 02:47:56 -0800 (PST) Message-ID: <0b001d74-5e4b-4dcc-86f1-55c67b1def33@bytedance.com> Date: Wed, 8 Jan 2025 18:47:49 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] sched/fair: Ignore isolated cpus in update_numa_stat To: Waiman Long , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, riel@surriel.com Cc: chengming.zhou@linux.dev, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org References: <20250103065930.413464-1-zhouchuyi@bytedance.com> <20250103065930.413464-3-zhouchuyi@bytedance.com> From: Chuyi Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Waiman, 在 2025/1/8 02:39, Waiman Long 写道: > > On 1/3/25 1:59 AM, Chuyi Zhou wrote: >> Now update_numa_stats() iterates each cpu in a node to gather load >> information for the node and attempts to find the idle cpu as a candidate >> best_cpu within the node. >> >> In update_numa_stats() we should take into account the scheduling domain. >> This is because the "isolcpus" kernel command line option and cpuset iso- >> late partitions can remove CPUs from load balance. Similar to task wakeup >> and periodic load balancing, we should not involve isolated CPUs in NUMA >> balancing. When gathering load information for nodes, we need to >> ignore the >> load of isolated CPUs. This change also avoids selecting an isolated CPU >> as the idle_cpu. >> >> Signed-off-by: Chuyi Zhou >> --- >>   kernel/sched/fair.c | 7 +++++-- >>   1 file changed, 5 insertions(+), 2 deletions(-) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index f544012b9320..a0139659fe7a 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -2125,6 +2125,11 @@ static void update_numa_stats(struct >> task_numa_env *env, >>       for_each_cpu(cpu, cpumask_of_node(nid)) { >>           struct rq *rq = cpu_rq(cpu); >> +        /* skip isolated cpus' load */ >> +        if (!rcu_dereference(rq->sd)) >> +            continue; >> + >> +        ns->weight++; >>           ns->load += cpu_load(rq); >>           ns->runnable += cpu_runnable(rq); >>           ns->util += cpu_util_cfs(cpu); >> @@ -2144,8 +2149,6 @@ static void update_numa_stats(struct >> task_numa_env *env, >>       } >>       rcu_read_unlock(); >> -    ns->weight = cpumask_weight(cpumask_of_node(nid)); >> - >>       ns->node_type = numa_classify(env->imbalance_pct, ns); >>       if (idle_core >= 0) > > You should initalize ns->weight to 0 first before iteration to prevent > pre-existing ns->weight value from corrupting the result. > > Cheers, > Longman > Thanks for your review. We have already memset ns to 0 before the start of update_numa_stats(), so I think it should be okay here.