From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (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 218E535F196 for ; Tue, 21 Apr 2026 18:19:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776795547; cv=none; b=NcDRx5JbSLFSxUxG1tcAUmFYAJuLBAOh6YGwgvxukVee+xfDwwzArJ6QuH09H8Go3PeT/m2o7+XusYyeQc7KvlzQMpTeCTPXOoeYm6iaIiwZM+KvmIK0rbgfgTn6zuZfC3xtFRRPErYLcDJHvJMo9rJr/nfRIhCD2nc9vYmgYzA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776795547; c=relaxed/simple; bh=oPEbfp36dBjMFYMndMugB7mBmT0SSQzvrn5zwN9Zb10=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KnpQLCUTJH7wf6HFF5pjmTeq+0OOHWBQ+2u6zcDYZYfaxLMOJdDev50qXFpaTdDxomcPqktBsxVKSTL/FvnPnvxCzTEcSfs4FywrTsoo6AN4tPmm12EDWu/gJSSJaUEGXQ3N0pKd5AwNQRtogFEQJ3gM8WbqDa+eRRc33+47lRo= 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=oPZ0c9ug; arc=none smtp.client-ip=209.85.210.180 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="oPZ0c9ug" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-82fbdd60b64so1506657b3a.3 for ; Tue, 21 Apr 2026 11:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776795541; x=1777400341; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=gUDFKv87nX4F7ZSX9m1mx5SoReNhVf8R+aQD1US3Z1A=; b=oPZ0c9ugFLpihjvMTC4fFK3o/W0sh4+CJp5RUwm/R/k4ID2bvHKy7Bce76Qjk3lOuv +VQWhr7DxStuI2UyMbmz8O+2wVGYnuXkAg07YLFREdJSJduDXystXrC4mIACaOdjkTzJ kijS55KOjMS/+Ovoj27WbNyrgXtbP9Wp9xsHAFeZ32q5BFat/ehZmggC+J0whyUYswUu 1zrbhZCQv77OlrKCIl+mv6ZvuP0+IQ1rucFZxG46yKKUCehYnW43TbCONt7w4CpHIoIc gbP2tB8Fjq7RDCirjI1Lfuma5qrKt+RwHz9NLHpsu1gKLUpOW4fhLffmp004KeTYFD7X cQGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776795541; x=1777400341; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gUDFKv87nX4F7ZSX9m1mx5SoReNhVf8R+aQD1US3Z1A=; b=oXJWqSs2i6kjWQNlln0gjQ7vmZazaQEJAjLE8oSCpu3yObzAO8aKzY4AwgczMFcsnr xz1heot2ksrd+8QmU5tUuUC/pywAMLjNcmvm2xaXHSc9jGs7tIBUG/NwA367Iy4kpA6t NliKqLqO3QCDqEQuhABYgRzKJdxz0wjWUkD+aHAfO3i1NTEDAA2rmYYUuKqmkQqSotXn LkXoKytm1s8l1NO9rktHfNxM+PKRvxLy9Ps5r0Q8fbf2VJ34LfmrHvn3UUu6XVq9hZSG f/4SoZ/tGo9dQNz4F9JdAyb/OhXPe3WzBNDu02lVcPFlqI6DywUBKGTS+W2yvABfij2z tQwQ== X-Forwarded-Encrypted: i=1; AFNElJ/slL2WhB424+yMMyavCVb6QBHRkbLDltA3b+3E30vqyg5v5/eHKQmMxT6QLV81PZVwMvznIsSUVWKe1ag=@vger.kernel.org X-Gm-Message-State: AOJu0Yx49NRRP1FpEF1hGJUWgxmSUjRbdB+d1Jkgo8O9l3v182GvSULL 7j+XPKyuk0I8gv3GDLojR4p4Y/yA/ubx+5QbvM8lj5Zpcp4mjoYzhASi X-Gm-Gg: AeBDieviRxj2fYMnxYXpb44Rexh/NH0dIjYF/zfM+P8ujC5EBni2lLLTVtM8HWuJSDT z2vm6vpqrc0hMWYBSzTAR2RasXg2kuihPyhy7Y3bPxHGcsLBIX1WOZYJXlk7ZIRWJ8Wl1/S8arY qPvt+J7ldj8+XDYkJWwy7IXaTzlNBfVyJG7EQ3M+fGwF0JAgD25azwNHP42pnZ8F7WCwRj7mi3y 1SGsMZygwHfATnDyOQflyECdlUxwM32+hNz14dN67eWpEv4RvvNnbVhqIfXrg0IjfOdsOLVFxwE 5KaSefYF7EYt8YzhJx4V5OkJa9JfAaCS5VT8nL8YqMQrQzTlXrJRKwsqYYVlGMJUC+DEp37BSvH pE74a0I6OV4DrcCPw6TDDWwbalMvhGcZUg4aTjqyiWoPEoSOL8//TFENXbzP+ACHHxTf+/M/rQq FRYb8YYmtq/Pe5D0DFpUBTWh2db+p7UYcYsau5JzJbqoMlYeovaDxZzUWmlYG2NRhXCV1eswWM3 kxh6I9cujou5Yjw X-Received: by 2002:aa7:88c7:0:b0:82f:42bc:3386 with SMTP id d2e1a72fcca58-82f8c889b28mr20004257b3a.21.1776795540809; Tue, 21 Apr 2026 11:19:00 -0700 (PDT) Received: from cchengyang.duckdns.org (36-225-97-241.dynamic-ip.hinet.net. [36.225.97.241]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-82f8ebe901csm17870268b3a.48.2026.04.21.11.18.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Apr 2026 11:19:00 -0700 (PDT) Date: Wed, 22 Apr 2026 02:18:56 +0800 From: Cheng-Yang Chou To: Tejun Heo Cc: void@manifault.com, arighi@nvidia.com, changwoo@igalia.com, sched-ext@lists.linux.dev, emil@etsalapatis.com, linux-kernel@vger.kernel.org, Ching-Chun Huang , Chia-Ping Tsai Subject: Re: [PATCHSET sched_ext/for-7.2] sched_ext: Topological CPU IDs and cid-form struct_ops Message-ID: <20260422015408.Gac88@cchengyang.duckdns.org> References: <20260421071945.3110084-1-tj@kernel.org> 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: <20260421071945.3110084-1-tj@kernel.org> Hi Tejun, On Mon, Apr 20, 2026 at 09:19:29PM -1000, Tejun Heo wrote: > Hello, > > This patchset introduces topological CPU IDs (cids) - dense, > topology-ordered cpu identifiers - and an alternative cid-form struct_ops > type that lets BPF schedulers operate in cid space directly. > > Key pieces: > > - cid space: scx_cid_init() walks nodes * LLCs * cores * threads and packs > a dense cid mapping. The mapping can be overridden via > scx_bpf_cid_override(). See "Topological CPU IDs" in ext_cid.h for the > model. > > - cmask: a base-windowed bitmap over cid space. Kernel and BPF helpers with > identical semantics. Used by scx_qmap for per-task affinity and idle-cid > tracking; meant to be the substrate for sub-sched cid allocation. > > - bpf_sched_ext_ops_cid: a parallel struct_ops type whose callbacks take > cids/cmasks instead of cpus/cpumasks. Kernel translates at the boundary > via scx_cpu_arg() / scx_cpu_ret(); the two struct types share offsets up > through @priv (verified by BUILD_BUG_ON) so the union view in scx_sched > works without function-pointer casts. Sub-sched support is tied to > cid-form: validate_ops() rejects cpu-form sub-scheds and cpu-form roots > that expose sub_attach / sub_detach. > > - cid-form kfuncs: scx_bpf_kick_cid, scx_bpf_cidperf_{cap,cur,set}, > scx_bpf_cid_curr, scx_bpf_task_cid, scx_bpf_this_cid, > scx_bpf_nr_{cids,online_cids}, scx_bpf_cid_to_cpu, scx_bpf_cpu_to_cid. > A cid-form program may not call cpu-only kfuncs (enforced at verifier > load via scx_kfunc_context_filter); the reverse is intentionally > permissive to ease migration. > > - scx_qmap port: scx_qmap is converted to cid-form. It uses the cmask-based > idle picker, per-task cid-space cpus_allowed, and cid-form kfuncs > throughout. Sub-sched dispatching via scx_bpf_sub_dispatch() continues to > work. I have gone through the entire patchset, and it lgtm. For the whole series: Reviewed-by: Cheng-Yang Chou I have two questions regarding the current implementation: 1. Regarding the ext_cid feature (same as ext_idle), is it feasible to implement this within the BPF arena instead of the current approach? 2. I noticed rust/kernel/cpumask.rs is already in tree. While I understand that arch support for Rust is currently limited, would it be a good time to start adding Rust abstractions to maintain parity or reduce code duplication? (as I discussed offline w/ Andrea about re-implementing ext_idle in Rust, and now w/ ext_cid as well) -- Cheers, Cheng-Yang