From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68F072E406 for ; Fri, 3 Jan 2025 11:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735904190; cv=none; b=LliSU2oHGy2AiKsja1+8oZq8iNf/oOmdTj9FcOUpmjXKZDpImS3X2ye37OAJ4qVZtl0h/JCS6g5eShIitq2AEYWv6iaP1FQrfybKAJjNbJv7+lNCF3sCMAMjbq+H0iZATU5Fx9pN6kPv77EMafZOepLdlz2vE8dX7qRxUN/Mwv4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735904190; c=relaxed/simple; bh=fsKiR3UZJj6vhZMaWirOapMHHvG5ddExDKmcJI/OgRo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MU9HNSGpDGz0R8zYfRWiUQV4R4bgerq70eXZd0M7T3Y7BjLBAIvXVeYxKVl4j+ladlzmu9SfaQzr0e4MDv/eUD17NrOaOXeY2XEyUuBsVmoaQ/9YNl04xcN96HSXEkOU1tdoMIh863VZ4+4W7gL/O0LrKikgRTUeo45NXxszEZ0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=nZ2haxN2; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="nZ2haxN2" 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=Yzoaan7ZvdyNN/sCS20K3g/QsIJPYq11TiYOS6ogr50=; b=nZ2haxN2bho0mx/cMTUNknHLrE pjOpngABtMYMOyXA32cPDGffNm1BPyHE0Vo+/G2gikN/8levIXdvv4xFXLc7imqGvn3OgLRcxYmTD GPd9bFu5YumeZahK9fVglQeChDv/MnK4yk/0p5GUXRmog2o8raurlmXm8zs7uGu6Lp9rg8Nn/Z/oC n9u5m+dL9K/Paz6ZgcFrYoRRdmi7HYrrGuerRQ8ysJhbAQGJhiHN/D9rEFPlul/DtXu4vXPUUqQey TsrPXaRrmhm+y0tJ666qDqz7v2BtoaY56c5veq7TnWvLQU04QzuLrw0w4yvwbkqZEo0jEq8K09e+K DXUen+Tg==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tTfyU-00000008NYg-0cDI; Fri, 03 Jan 2025 11:36:18 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 828493003AF; Fri, 3 Jan 2025 12:36:17 +0100 (CET) Date: Fri, 3 Jan 2025 12:36:17 +0100 From: Peter Zijlstra To: Chuyi Zhou Cc: mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, longman@redhat.com, riel@surriel.com, chengming.zhou@linux.dev, kprateek.nayak@amd.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/3] Take the scheduling domain into account in numa balancin Message-ID: <20250103113617.GE22934@noisy.programming.kicks-ass.net> References: <20250103065930.413464-1-zhouchuyi@bytedance.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250103065930.413464-1-zhouchuyi@bytedance.com> On Fri, Jan 03, 2025 at 02:59:27PM +0800, Chuyi Zhou wrote: > This patchset tries to adjust the logic of handling isolate cpus in numa balancing. > > patch#1: Clean up for task_numa_migrate(). > > patch#2: Skips the isolate cpus when gathering numa status and finding > idle cpus in update_numa_stats(). > > patch#3: Ensure that we do not select an isolated CPU in > task_numa_find_cpu(), even if it is present in the task's CPU mask. Your $subject and actual patches do not patch. Your subject suggests you're taking the scheduling domains into account for numa balancing, your actual patches are bunch of special case hacks that totally ignore the actual sched domains :-(