From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (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 293893BFE22 for ; Wed, 4 Feb 2026 09:53:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770198808; cv=none; b=mN5KqvH7QVdOvtYGGom/6kG/FC2nRZiBhBoPBx+Xlysms8vQZq44mUsmcHQF1DzEwvB/ayBu+xlc+p28sXHHk2u+YMLkEbl+rqYq8WjUSN62yCHcN4jlCKKN8I8rWdpkugrnMRzG4ZFD2h3js2NF5ib67vHXobyjsrUj+I8nQvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770198808; c=relaxed/simple; bh=ZoPUjYnfDa0+UaCJeDPuqkllxoFjwIAl37TBgkVzDoI=; h=Message-ID:Date:MIME-Version:From:Subject:To:CC:References: In-Reply-To:Content-Type; b=ZfrjATW815uXxbEslfdy4jvTJBqhY2+j6k2R+LF9vQJ8NC7Btqs2IctKjzq8nSUUtUrT4220YlpSzjT+0HD/cQaUy3zHeqmcSOox+bqjYRvX5wP1aBeM03eVTsgnciDt1K6tDH7rnNpDvdyV3ZAF4CW+HQMAsnuIO+7FeZqWW08= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=alDdfeG7; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="alDdfeG7" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=lucelpwJFWkIsKwKMCkY9ZeebQjb+Vxl7uW6G8wKBtw=; b=alDdfeG720Qa2reE7VOvrq08OLnXrnx/ac4fRfrbwRwXjpPNlF+Vwr6OXbsxtq/tTh8fF5ZTs 940OEZ6Lfy+vDY5/6mZe1r4juNpwX+u6nfQXwHcTBF7hxIGNp8XJrBPo7zK0PxkZZQ6vjB8gPJK zRsHgkMfbCDBNVqKGT0WdpU= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4f5bCM2qr6z1prLm; Wed, 4 Feb 2026 17:48:47 +0800 (CST) Received: from dggemv705-chm.china.huawei.com (unknown [10.3.19.32]) by mail.maildlp.com (Postfix) with ESMTPS id 18DAB40569; Wed, 4 Feb 2026 17:53:24 +0800 (CST) Received: from kwepemn100008.china.huawei.com (7.202.194.111) by dggemv705-chm.china.huawei.com (10.3.19.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 4 Feb 2026 17:53:23 +0800 Received: from [10.67.120.139] (10.67.120.139) by kwepemn100008.china.huawei.com (7.202.194.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Wed, 4 Feb 2026 17:53:11 +0800 Message-ID: Date: Wed, 4 Feb 2026 17:53:08 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: wangyushan Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC To: Linus Walleij CC: , , , , , , , , , , , , , , , SeongJae Park , Yushan Wang References: <20260203161843.649417-1-wangyushan12@huawei.com> <20260203161843.649417-2-wangyushan12@huawei.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To kwepemn100008.china.huawei.com (7.202.194.111) On 2/4/2026 8:10 AM, Linus Walleij wrote: > Hi Yushan, > > thanks for your patch! Thanks for review! > On Tue, Feb 3, 2026 at 5:18 PM Yushan Wang wrote: >> The driver will create a file of `/dev/hisi_l3c` on init, mmap >> operations to it will allocate a memory region that is guaranteed to be >> placed in L3 cache. >> >> The driver also provides unmap() to deallocated the locked memory. >> >> The driver also provides an ioctl interface for user to get cache lock >> information, such as lock restrictions and locked sizes. >> >> Signed-off-by: Yushan Wang > The commit message does not say *why* you are doing this? >> +config HISI_SOC_L3C >> + bool "HiSilicon L3 Cache device driver" >> + depends on ACPI >> + depends on ARM64 || COMPILE_TEST >> + help >> + This driver provides the functions to lock L3 cache entries from >> + being evicted for better performance. > Here is the reason though. Sorry, I will include this into the commit message. > Things like this need to be CC to linux-mm@vger.kernel.org. > > I don't see why userspace would be so well informed as to make decisions > about what should be locked in the L3 cache and not? This question is actually: should it be kernel or user space application to decide if a cache lock should be applied? Maybe the ideal situation is that this capability should be reserved into kernel space as a vendor specific optimization option. With the lack of knowledge of memory interleave etc the best move of an application might be allocate cache lock as much as possible. > I see the memory hierarchy as any other hardware: a resource that is > allocated and arbitrated by the kernel. > > 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=xKJO4kLTHOI > > Shouldn't the MM subsystem be in charge of determining, locking > down and freeing up hot regions in L3 cache? Thanks for the link, I will see if there's any chance this can cooperate with DAMON. Gaps still exists here because DAMON operate with pages, but cache works with cachelines, though the cache lock here supports cache lock size larger than a page. > This looks more like userspace is going to determine that but > how exactly? By running DAMON? Then it's better to keep the > whole mechanism in the kernel where it belongs and let the > MM subsystem adapt locked L3 cache to the usage patterns. Currently the patchset simply trusts that user knows well what he is doing, which might not be good enough. I will try to see if this could work with DAMON or madvice() maybe :) > Yours, > Linus Walleij Thanks, Yushan