From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f179.google.com (mail-dy1-f179.google.com [74.125.82.179]) (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 04621A92E for ; Fri, 16 Jan 2026 06:07:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768543667; cv=none; b=tMO91Fc308ISy72d9NaNwmIKOCfd1voB6mQ46n7ddYYpxrWNYMHsKisVawuXwJC0aLNlqmp+Hsg11CZuhcJRRk1/Qfc4x4ksey2efBnMBZXwTacwRxLtajVQ3wZQAze8X4eaZOrpNlGDQ5Nbc2+uJRdn1YiQG4C9wb7erIIINao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768543667; c=relaxed/simple; bh=kAo5GY2HOD6erJYNvhZLaghrrNmaRoiKlocuVXULrgs=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=PtrsNOwJ+m1skWWcZKW6YidTe9r2R0P6yAB1pAr9RlKZtUkz5BYGFzen/qsETCsafP76C/ydPITH7zLNIQIA1ScGKHFnkKAksGTMciQDwKL50dP+K3wXfMjhkeCpOqXpeXDcWxPjQowkuUTKiObE+/1PEqNdSldxsGXGoXyaGfg= 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=DCFsaXke; arc=none smtp.client-ip=74.125.82.179 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="DCFsaXke" Received: by mail-dy1-f179.google.com with SMTP id 5a478bee46e88-2b6a93d15ddso1220448eec.1 for ; Thu, 15 Jan 2026 22:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768543665; x=1769148465; 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=6+wYykjIWhJAiIrhxgUD60+twdlUXB8UVk9AYpFC0BI=; b=DCFsaXke/g+BNw5n4OT/QeugufRAUf+/GvNa+VMh1uEtrMpuuJ/+JHfDjZhOygls0T YxSdcag4rzHhCGq8/bn4ZOlfVnaDdxZOYlQ59hCmY64U91E8T4fq1PE3LMCEIE0CUPHE DSeIZk77E3PYivj45Sa1A5ZzNfVjzkh5mOgajjtJSpIU0vWnUj+xv1TZWmybNjWZiv3Q 9ZCCRI22sKcS32rwiAyPOPpYqvI4VvCCHQVWzBLo3/Gve+krAqjwUWMW3bGt21DDnEbF tVQA3/MlnCiGNStpUWUktNoP9KZVTpKNHIWugEqKSt8PsO44jD6q0epmI1isGTmW1Sn2 eBzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768543665; x=1769148465; 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=6+wYykjIWhJAiIrhxgUD60+twdlUXB8UVk9AYpFC0BI=; b=lOm2bJR3goRGNphPXeb2KPaOJ1CrqNrGF/bRIzNaHc6ngdgb4WCBR/pOYhQVUYV/SV boYD8RjowylPNlEZwliiL17JyNO+Ee/4eAx1qTdRDDs98H70yug7wyRDHRO0rm+AOtK9 Fr2PGSnMkwmN2ztmavmuWl48P6OrTvxzhh+AhwnESqBdUXfzwRyWdWrxm7TWBuG2uVvu Cif1Bb2WM6hEu5W0d+impTUKk3nC49yP8QK4x9mlESFq3L0V4MUSdNWF+tgFjc9XG1hT ITRmwUxLvAxY2bXnnhb9H8Po8zzq1Vxuhf9LIJL5Rq9beyOvAmk0EaqJA/JbOrpmN5Oj 19SA== X-Forwarded-Encrypted: i=1; AJvYcCVEV89fFRH8JV2ewwdAVcRICjRvP6GItt2J2RwEI3YGmqawkui95u6a9YNgyYBaG2+Kahj8Ze6PFXf/x7U=@vger.kernel.org X-Gm-Message-State: AOJu0YzDGVufe+x8IyZqTZsY3xo+QqZcc9MmsIMXqOVG7zR4/iKpPxeo Ozxne4PQ3JxJisNO8AEBoAmv9p/8fmHomOrDBzH1IjO/0fPJVbTYODcp X-Gm-Gg: AY/fxX66zW3o2spXqXJVMvi5MkZtjHN1lWcI6aw6ryrhCMMdwHj91mSQD0E1HRrmiwA H5qHMQWQjivrDkPZ7hWvQsP8t3WqVzZZ3sCRbNyW/mjfF+AybUvAxdAksUpbMbItrDVQbuUMaVl 85JcqnEjLs/TTnH0Ct79n0jlaYO5fvXoQcSf1gyeeSydx+8Car3gaLNOS2az0f6ftEDBqeBsKWp 3A+YXnh3poI7hV1ZPZYbyC8IySQAMk4fRKCPXNbA+xRlC6DUe4PzbOQdP9cx3SdLCpJYP/soNn3 AqX//FjK2eRmi5iMHqc69dBmW47630mzHwwW0EJQgdMxA8DB0DbsFHXdcqaPxMSZVAq8hTe+xEI dgNkYM4gyL6yuVzDV0Q4BS4IPMXVTEzdpcKXpK7vcsESZAGrbyiQsZvbrgf5jCVWjx430ObRv8N A40jb8eXRMFEg+IkN3BuBSRNAz5OhN5YfbYQ== X-Received: by 2002:a05:7300:6420:b0:2b0:4b5b:6820 with SMTP id 5a478bee46e88-2b6b40b392bmr1797267eec.26.1768543665004; Thu, 15 Jan 2026 22:07:45 -0800 (PST) Received: from localhost.localdomain ([74.48.213.230]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2b6b361df88sm1239546eec.18.2026.01.15.22.07.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Jan 2026 22:07:44 -0800 (PST) From: Qiliang Yuan To: eddyz87@gmail.com Cc: andrii@kernel.org, ast@kernel.org, bpf@vger.kernel.org, daniel@iogearbox.net, haoluo@google.com, jolsa@kernel.org, kpsingh@kernel.org, linux-kernel@vger.kernel.org, martin.lau@linux.dev, realwujing@gmail.com, sdf@fomichev.me, song@kernel.org, yonghong.song@linux.dev, yuanql9@chinatelecom.cn Subject: Re: [PATCH] bpf/verifier: compress bpf_reg_state by using bitfields Date: Fri, 16 Jan 2026 14:07:35 +0800 Message-Id: <20260116060735.35686-1-realwujing@gmail.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <7ffce4afdb0e859df7f0f87d170eda31b66a5b2b.camel@gmail.com> References: <7ffce4afdb0e859df7f0f87d170eda31b66a5b2b.camel@gmail.com> 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 Eduard, On Thu, Jan 15, 2026, Eduard Zingerman wrote: > varistat collects verifier memory usage statistics. > Does this change has an impact on programs generated for > e.g. selftests and sched_ext? > > In general, you posted 4 patches claiming performance improvements, > but non of them are supported by any measurements. > > P.S. > Is this LLM-generated? Thank you for the feedback. I would like to clarify that these optimizations are the result of a deliberate engineering effort to address specific performance bottlenecks in the BPF verifier. These improvements were identified through my personal code analysis over the past two months, though I have only recently started submitting them to the community. Regarding the impact on selftests and sched_ext: I have verified these changes using 'veristat' against the BPF selftests. Since these optimizations target the core verifier engine and structural layout, they benefit any complex BPF program, including those in sched_ext. The results show a clear reduction in verification duration (up to 56%) and peak memory usage (due to the reduction of struct bpf_reg_state from 112 to 104 bytes), with zero changes in the total instruction or state counts. This confirms that the verification logic remains identical while resource efficiency is significantly improved. The specific order and context of the four patches are as follows: 1. bpf/verifier: implement slab cache for verifier state list (https://lore.kernel.org/all/tencent_0074C23A28B59EA264C502FA3C9EF6622A0A@qq.com/) Focuses on reducing allocation overhead. Detailed benchmark results added in: (https://lore.kernel.org/all/tencent_9C541313B9B3C381AB950BC531F6C627ED05@qq.com/) 2. bpf/verifier: compress bpf_reg_state by using bitfields (https://lore.kernel.org/all/20260115144946.439069-1-realwujing@gmail.com/) This is a structural memory optimization. By packing 'frameno', 'subreg_def', and 'precise' into bitfields, we eliminated 7 bytes of padding, reducing the struct size from 112 to 104 bytes. This is a deterministic memory saving based on object layout, which is particularly effective for large-scale verification states. 3. bpf/verifier: optimize ID mapping reset in states_equal (https://lore.kernel.org/all/20260115150405.443581-1-realwujing@gmail.com/) This is an algorithmic optimization similar to memoization. By tracking the high-water mark of used IDs, it avoids a full 4.7KB memset in every states_equal() call. This reduces the complexity of resetting the ID map from O(MAX_SIZE) to O(ACTUAL_USED), which significantly speeds up state pruning during complex verification. 4. bpf/verifier: optimize precision backtracking by skipping precise bits (https://lore.kernel.org/all/20260115152037.449362-1-realwujing@gmail.com/) Following your suggestion to refactor the logic into the core engine for better coverage and clarity, I have provided a v2 version of this patch here: (https://lore.kernel.org/all/20260116045839.23743-1-realwujing@gmail.com/) This v2 version specifically addresses your feedback by centralizing the logic and includes a comprehensive performance comparison (veristat results) in the commit log. It reduces the complexity of redundant backtracking requests from O(D) (where D is history depth) to O(1) by utilizing the 'precise' flag to skip already-processed states. Best regards, Qiliang Yuan