From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 DA97335AC13; Sat, 16 May 2026 09:12:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778922744; cv=none; b=oPCfgUnVFJ1gL1KgCILQux7tco1901D3g7Easnj4yaBHmujHc19qWqYAmxotIHh3vP+7JqoAYVSkLa5VH9hx7EGAiy4Po6vyURtR1kW9L+OWSLSPYwKZWSxrz6WrHDyuu6fQw/Ik+97anpjeedGCeXjajhuK0bXP/l4dyh8PFWg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778922744; c=relaxed/simple; bh=LL/S8GnS0b1/dCWxejuLJBEUJ6lauWpm0bwiV4rKpLg=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=l1CfBRp/0dzUux7gXM98mhxri6ePyczKMEuzHtaY7qMQcxbjBC+MuFGeIKs31sox04DuKHtrwYQcugvWNUYXepooZU80cZ4zHwba5W9OyQsWaU3e2PDDo/FtLu1A1oAGepJiBYGNhTXgJswEiGam3Y9wIRRCY0SuOvzhfZ8Sx34= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a5pOYwIN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a5pOYwIN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70015C19425; Sat, 16 May 2026 09:12:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778922744; bh=LL/S8GnS0b1/dCWxejuLJBEUJ6lauWpm0bwiV4rKpLg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=a5pOYwINvYqAl5OspBjpye/1VsuInGuPHtwMdtgKAy9sVNjuaTTYWYKZQ0K5svlLC PQF5OXTUcKMM5w76tnoj96E0nsfZPrCErhPjx6bnUC8sXBUTP1Q7cxp6SbFfYwhYOR VaJ2tzWLLUaDRcvIkk4Lei0RurttnH3Nzs2hu+mezRlP1Q8OXoQ1C/1YVki0Jyl5Wm aXVUDrB/Qqb495t+4qvPgF+lzL/VCKRgA/MM419MeVDojCw/ZGsQ0Zq6X4fO1btvaC hcVGPUw6sJq9J+iZ2MXh8/O2qONnxLX8YrznPM66yQGd6F4cqNllVxRoVlOLcFGkVg o9Fnegvl5s3Lg== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wOB4I-00000002xtC-0blF; Sat, 16 May 2026 09:12:22 +0000 Date: Sat, 16 May 2026 10:15:36 +0100 Message-ID: <87o6ifaf5z.wl-maz@kernel.org> From: Marc Zyngier To: Leonardo Bras Cc: Oliver Upton , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Fuad Tabba , Raghavendra Rao Ananta , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/2] Optimize S2 page splitting In-Reply-To: <20260515195904.2466381-1-leo.bras@arm.com> References: <20260515195904.2466381-1-leo.bras@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: leo.bras@arm.com, oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, tabba@google.com, rananta@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 15 May 2026 20:59:01 +0100, Leonardo Bras wrote: > > While playing with dirty-bit tracking, I decided to take a look on how page > splitting works. Found out all entries are walked, even though we can infer, > for instance that: > - If a level-3 entry is walked, it means the parent level-2 entry is split > - If a split just succeeded in an table entry, it means all children nodes > are already split > > So I tried to optimize it in a way that it does not break other users. > > My main idea is to introduce positive return values that hint to the > pagetable walking mechanism that either siblings or children can be > skipped. That should be contained to the visitor function, that returns > zero if no error was detected. > > Numbers on above optimization are promising: > A 1GB VM, running on the model, splitting all at the beginning > (no manual protect): > - Memory was already split (4k pages): -97.33% runtime (-172ms) - 20 runs > - THP backed memory: -19.82% runtime (-153ms) - 10 runs > - 1x1GB hugetlb memory: -20.65% runtime (-150ms) - 10 runs > I haven't looked at the changes in details, but the methodology is quite flawed. For a start, measuring anything on a software model (QEMU or FVP) doesn't mean anything performance-wise. The trade-offs are completely different from a HW implementation, and even the notion of time is pretty inconsistent. Please run this on actual HW. I'm sure your employer can give you access to one of these mythical arm64 toys. Measure things from userspace, not from the kernel, so that you have all the overheads. Don't add console output, because that will make things far worse. I'm sure you can hack one of the selftests for this purpose. Thanks, M. -- Jazz isn't dead. It just smells funny.