From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com [209.85.167.173]) (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 B9E083D7D94 for ; Wed, 4 Feb 2026 11:36:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770205013; cv=none; b=Ciu308wTbM1HvnyOwsDxwxX6rYSFWgEcU2SN+iP3axOYFxon1xm4QLz3w6hAj6/f227SaUoiIn+rqTzmXJw3321KaU/JurMbklrDOfIUg5EFRoT51ghJWW2MBjtnfBdqqwJ5BPHYHjECY59xt380RWUd92WoSzVeE6IkxJZnu3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770205013; c=relaxed/simple; bh=RknE2qaMvd+Ec3BSU4pR4Us57yVfETvAFmPmZxmCSUc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jCNkflWot7W/iXdJ6MXqPkhz9pmloaTpkuV7PtqB/5h1FoOM10oatY7L5EaY4wQCEeZa7u7xw75RNImZ4dDEVueAaebc85ivFnaVrcv/8gdOh6XBAArWn9QTzS8irsM3yB3YBK9AkU9dfDCx/vx/CF+9cmP9I26+TYh2zbznf0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=O7msqPRs; arc=none smtp.client-ip=209.85.167.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O7msqPRs" Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-45f004e7d71so548066b6e.1 for ; Wed, 04 Feb 2026 03:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770205011; x=1770809811; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=RknE2qaMvd+Ec3BSU4pR4Us57yVfETvAFmPmZxmCSUc=; b=O7msqPRs8IoK9UJy0IzX2/UtF1j8ktynXIAsvXGC+BNb2FVNLXMSB2WWwMJVUrF7at 4vz0OyvBCiCU5ShbWkECIPV6QBKCD9MBkcNI4mhKSgKK9vnLVcjcovAt4DlxjZw/5NJJ UgwQBDfhh1AC1CLVTiCPHeaG0PAYNdmr0ZCK/utBKv1tel4gqqav/xaUXCqynQi8AX6P z3mu96t3cBe9Ie4K+4DlEiutvcyO8MFN01fGMJz3YlWQgxYs7rs1Io6ChbdQYPNjulFB Fg8tIzkcsjqoqPfkgFX9a95XTihMGUP6iAYH74jeBuDP+7IQ0Wowp+uw+7FYkYcBHEQi ugHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770205011; x=1770809811; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RknE2qaMvd+Ec3BSU4pR4Us57yVfETvAFmPmZxmCSUc=; b=bF+KlRCnYFSn4SfuqcsquSUp2J6gOVrle6qZhBNE5qZEBuKPRtzJfTYJySqHPQuoEl MS94DxDxmcd9Qksj+Z5+oVtY5DmMMEgguoWajpHRejwtHq/xV1mILnHZ3Q84AM1yYRJJ Zu5mIK4neH4RFfbTApFJh6YvhBL9GeK9ni1v5THqGmD3jKzYqEn4Q+ouj5Oj30qc/fjH y4GqUKIKAF9gLkGhFEzPMWUgWk9TycPX+jVOqesBq08Q8SckrUn95MsWMdXxPSBOEHxy SKveL2+h4+7sOFqFZTFnuFdOrUYalNhlvHVRrTh4qE/OBi78noruHzQ8NZUY0hY2TZGn L1RA== X-Forwarded-Encrypted: i=1; AJvYcCX9b3R2wK2HoeJO5fRbPWBm4uzCT+EGZ2L5Em3EZoIyrur6P0WpurZzIDf6KT96L6UZs1a9ztqcTrAYJ7Q=@vger.kernel.org X-Gm-Message-State: AOJu0YzLShHS43GcbSnu7Jz4n8v2w0A3fHnPw/KKwk79EgvLSF7V8sJ8 NmgGaxBXD4KJlg474FGnNA9aZMEZ4hDbrb8M/E7r3GnhtqFrzeBcUe8yK06Yc0KgGSRP5Q== X-Gm-Gg: AZuq6aJF6PF7Lg1f65aifsGuYfKDAkHL+/qYqEAvte0HvtHFu0QYb4Wja+wpjld81gk OGw6XPhxlE/vXOj/EhAL28l4LUuTC0HRzE1qezqGYp94scYXnF4EUxsRQ8LgUeFNicq8GAmrINZ F1hlRlv2blWk4OCraOQwbZCDjplBG1UAiXOnyZ2OBlJlaUFVSkjgqYbe70q6HcFarzvlbJeHNkQ P6knv/ugTLxu05/jB6NYKQA9LQT9oWbguu6I0QOCsuUl69jRr2sPBMHJMqLRATnD/3K3DYrQYgC 71JzNtOPpVtcdUtFp3ojcXoQfEq13kSslz9a1oKVFLJOdcHXInCdi4s9vvzdbrISi7rbdcJiuye z8iYUky7ZpHAwXQipWQ/kl5LScG42VIhRV/im0S34b7Bi45C8IdBXhRAsH8XwUtDajax5haLuKI tiyEg= X-Received: by 2002:a05:7300:1802:b0:2ab:9d23:f0b1 with SMTP id 5a478bee46e88-2b820efade0mr2048673eec.13.1770198132127; Wed, 04 Feb 2026 01:42:12 -0800 (PST) Received: from debian ([74.48.213.230]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b832e1296dsm1265103eec.4.2026.02.04.01.42.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Feb 2026 01:42:11 -0800 (PST) From: Qiliang Yuan To: arighi@nvidia.com Cc: bsegall@google.com, changwoo@igalia.com, david.dai@linux.dev, dietmar.eggemann@arm.com, emil@etsalapatis.com, jake@hillion.co.uk, juri.lelli@redhat.com, linux-kernel@vger.kernel.org, mgorman@suse.de, mingo@redhat.com, newton@meta.com, peterz@infradead.org, realwujing@gmail.com, rostedt@goodmis.org, schatzberg.dan@gmail.com, sched-ext@lists.linux.dev, suzhidao@xiaomi.com, tj@kernel.org, vincent.guittot@linaro.org, void@manifault.com, vschneid@redhat.com, yuanql9@chinatelecom.cn Subject: Re: [PATCH] sched/ext: Add cpumask to skip unsuitable dispatch queues Date: Wed, 4 Feb 2026 04:41:58 -0500 Message-ID: <20260204094202.3917675-1-realwujing@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi Andrea, I have fixed those issues in v2: https://lore.kernel.org/all/20260204093435.3915393-1-realwujing@gmail.com/ On Tue, Feb 03, 2026 at 09:37:14AM +0100, Andrea Righi wrote: > Did you run some benchmarks / have some numbers? I'm working on collecting more detailed benchmark numbers. However, theoretically, the bitwise cpumask_or() should be much cheaper than a DSQ scan that results in multiple cache misses during task structure dereferencing, even for small queues. > It's true that we save the O(N) scan when the DSQ has no eligible tasks, but we're > adding cost on every enqueue: cpumask_or() on potentially large cpumasks can be > expensive. > ... for small queues or mixed workloads, the cpumask overhead probably exceeds > the savings... To minimize the enqueue overhead, I've optimized the dispatch_enqueue() path in v2: - Use cpumask_copy() instead of cpumask_or() when the task is the first one in the DSQ. - Skip the cpumask_or() update if the DSQ's cpus_allowed mask is already full. > The cpumask is only updated during enqueue and cleared when the queue empties. If a > task's affinity changes while it's already in the queue (i.e., sched_setaffinity()), > the cpus_allowed mask becomes stale. Fixed in v2. I've added a hook in set_cpus_allowed_scx() to update the DSQ's cpus_allowed mask whenever a task's affinity changes while it is enqueued in a DSQ. > I don't see the corresponding kfree() in the cleanup path. Fixed in v2. I've added an RCU callback (free_dsq_rcu_callback) to explicitly free dsq->cpus_allowed before freeing the DSQ structure itself. Also, I've restricted the cpumask allocation to user-defined DSQs only, as built-in DSQs (local, global, bypass) don't need this optimization. Thanks, Qiliang