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 354CD37AA92 for ; Thu, 5 Feb 2026 09:12:45 +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=1770282766; cv=none; b=AG6U4hfJqhyefpA6td5yjXD4C4nJT1VKe/zaoLVPmQaf+ysFce+iOHL3xQ29gO7B2W5NnrKE8/UyR0kAGRt4RwlXmWxAGPzwb5A1j/FheZUU8jj1tDW46c2s31ob8QNMHbGloBYhKCpA41jAjgQLx2PZxv9kdyShjlBYw53M7v8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770282766; c=relaxed/simple; bh=0VYoSDstxiT7/zIXTYviYDaUyON+OJnVTGDLwtgMuK8=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=AUTEbWfbZhXVRQyIddxIN33lTq89rqFEfikPoKY4qM7dGxeV/JpolzNtWA1t/MxQ8/k75YyvKesC/CYOdq1UiRFcUPEiJ0spLetxx7NsF7PAvtpAh/TqbX+pxlPDq+lHfXs2L6VSMAONJ3O5F2IP9WGM3wqUIKHAuRYiz/BsvRE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hAh2EVYe; 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="hAh2EVYe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3A21C2BCB1 for ; Thu, 5 Feb 2026 09:12:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770282765; bh=0VYoSDstxiT7/zIXTYviYDaUyON+OJnVTGDLwtgMuK8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hAh2EVYewNSM7losKcE/8wHBl8u2rt7OWGdyrHMZY5eZDU3zmB+tYm7ecKvtmsUHG kuvXJ8+h2CTghbSoLOyLUY7uLgyXp34RHC2gWU0NG8E48v0RgHeH6xdOnfvSOYa5rx bn+Ta95pBvQpsGq1em9Qzo+YdBhZO8ZB1f053FwPTEK4hxPxhl3b+3jzuoLsp9yjF4 hYXpC4u5onXeSQehHfZUFJP4re1/F1bQnJ4MQBMOzB7lQxNXKOHlEZFgq9XEfArgGj ChYFaijlcXp7bEUnORSJpRKo4XGbah3JQxejZC4nHxyRTv6h6ptfjuLpQ8O5xyCkYy k47jBOHjuGaPQ== Received: by mail-yx1-f44.google.com with SMTP id 956f58d0204a3-649b1ca87ddso833711d50.3 for ; Thu, 05 Feb 2026 01:12:45 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCW7Hl2GHkKhihqPIXhJ0F90IgMgUhytc+tH7qhG2qeX5KARSdK7UzZwWQQU1FXmtKO77NFjf/GmZL5mXCg=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/dFCulPDjKi+SL02H8Qh02yOiEzU8eQN1YRUV6H0k0wr5LnvC bLl4q+L34BN8OEYzkuH92zDODXuVgIma+fW4aMFRSqtfQxRuBy3Y9Ikgbxs9nbiB7xh4OqlcWc1 qzdZvj2fWVeNqZb9rWf1PU+v3gRNFy3w= X-Received: by 2002:a05:690e:2108:b0:649:c36a:a9d5 with SMTP id 956f58d0204a3-649db341589mr3488280d50.32.1770282765028; Thu, 05 Feb 2026 01:12:45 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260203161843.649417-1-wangyushan12@huawei.com> <20260203161843.649417-2-wangyushan12@huawei.com> <20260204134020.00002393@huawei.com> In-Reply-To: <20260204134020.00002393@huawei.com> From: Linus Walleij Date: Thu, 5 Feb 2026 10:12:33 +0100 X-Gmail-Original-Message-ID: X-Gm-Features: AZwV_Qjg88fpqtNW8DkpBzZtACEt1hAPLR3BpHGpNsKsu27kCes581pWrn13njI Message-ID: Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC To: Jonathan Cameron Cc: Yushan Wang , alexandre.belloni@bootlin.com, arnd@arndb.de, fustini@kernel.org, krzk@kernel.org, linus.walleij@linaro.org, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, fanghao11@huawei.com, linuxarm@huawei.com, liuyonglong@huawei.com, prime.zeng@hisilicon.com, wangzhou1@hisilicon.com, xuwei5@hisilicon.com, linux-mm@vger.kernel.org, SeongJae Park Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan, thanks for stepping in, I'm trying to be healthy sceptical here... What you and others need to do is to tell me if I'm being too critical. But right now it feels like I need some more senior MM developers to tell me to be a good boy and let this hack patch slip before I shut up ;) On Wed, Feb 4, 2026 at 2:40=E2=80=AFPM Jonathan Cameron wrote: > > The MM subsytem knows which memory is most cache hot. > > Especially when you use DAMON DAMOS, which has the sole > > purpose of executing actions like that. Here is a good YouTube. > > https://www.youtube.com/watch?v=3DxKJO4kLTHOI > > This typically isn't about cache hot. It it were, the data would > be in the cache without this. It's about ensuring something that would > otherwise unlikely to be there is in the cache. OK I get it. > Normally that's a latency critical region. In general the kernel > has no chance of figuring out what those are ahead of time, only > userspace can know (based on profiling etc) that is per workload. (...) > The only thing we could do if this was in kernel would be to > have userspace pass some hints and then let the kernel actually > kick off the process. (...) > and you absolutely need userspace to be able to tell if it > got what it asked for or not. (...) > Its an extreme form of profile guided optimization (and not > currently automatic I think?). If we are putting code in this > locked region, the program has been carefully recompiled / linked > to group the critical parts so that we can use the minimum number > of these locked regions. Data is a little simpler. OK so the argument is "only userspace knows what cache lines are performance critical, and therefore this info must be passed from userspace". Do I understand correctly? What I'm worried about here is that "an extreme form of profile guided optimization" is a bit handwavy. I would accept if it is based on simulation or simply human know-how, such as if a developer puts signal-processing algorithm kernels there because they know it is going to be the hard kernel of the process. But does the developer know if that hard kernel is importantest taken into account all other processes running on the system, and what happens if several processes say they have such hard kernels? Who will arbitrate? That is usually the kernels job. > I haven't yet come up with any plausible scheme by which the MM > subsystem could do this. I find it kind of worrying if userspace knows which lines are most performance-critical but the kernel MM subsystem does not. That strongly inidicates that if only userspace knows that, then madvise() is the way to go. The MM might need and use this information for other reasons than just locking down lines in the L3 cache. In my mind: Userspace madvise -> Linux MM -> arch cache-line lockdown So the MM needs to take the decision that this indication from userspace is something that should result in asking the arch to lock down these cache lines, as well as re-evaluate it if new processes start sending the same madise() calls and we run out in lock-downable cache lines. L3 lock-downs is a finite resource after all, and it needs to be arbitrated. Just OTOMH, maybe if several processes ask for this simultaneously and we run out of lockdownable cache lines, who wins? First come first served? The process with the highest nice value or realtime priority? Etc. I.e. the kernel MM needs to arbitrate any cache lockdown. Bypassing the whole MM like this patch does is a hack designed for one single process that the user "knows" is "importantest" and will be the only process asking for cache lines to be locked down. And this isn't abstract and it does not scale. We can't do that. That's the kind of resource management we expect from the kernel. MM might want to use that information for other things. > I think what we need here Yushan, is more detail on end to end > use cases for this. Some examples etc as clearer motivation. I agree. Yours, Linus Walleij