From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (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 BE7883E4C6E for ; Tue, 28 Apr 2026 09:03:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777367009; cv=none; b=LwHVQQKGictlLROXGV1I5hOEfQMCeWztjXYm9PUOIHO6Xklu70rm3cv6vdDNXzjzlPOKMpxS7Lksl/ZCOHvlFo+E3dEenRmsqn9GeaHwg/ZM5/yEWuZ6Ww3uKQdbjehDfMoNlqjLw3bKGOKzGAINOE/uavUMoJzndUbmpmeC9IM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777367009; c=relaxed/simple; bh=PCg341CEvH/iElDQ5yNTrI97030Jl1V/2iyPh/9j4zo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p+IP7s8HokZ3GmJgNdzJ/rJUjW6+swszVE9DeMmClghCOp0MTHbfYOJLi/gNBT/DYRPkGMJft/pcQdrr5CaawQ4a1B0Wecv8zYURQX/K12JJDUDcWDNeyJKYxV0CE+W4lAxGOZzZtdCZgE1d1n4s+URDulE9d343YrhvIscdbN8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=jzW+RS/+; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="jzW+RS/+" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1777367003; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; bh=ipahEW+GGYKoUkQjhbzDfkF4W3Q2W6HmS1nNqAHycr8=; b=jzW+RS/+QPw0ah3ql3B1IYAdfDhIlYIMbniWsHNHMtAL1DiHrUi26oZ1ZCxrENF9xp+Vb8wgW2biALSpYuBxU/VMwyRkMjlSM6c9athnZdfPibh19gB2/eFwMIdRqIaA7Rd+0m5jU95rSpyX6g3i6TBFUdS0DlKIx9Am7s156/0= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033045098064;MF=feng.tang@linux.alibaba.com;NM=1;PH=DS;RN=19;SR=0;TI=SMTPD_---0X1u5t9W_1777367001; Received: from localhost(mailfrom:feng.tang@linux.alibaba.com fp:SMTPD_---0X1u5t9W_1777367001 cluster:ay36) by smtp.aliyun-inc.com; Tue, 28 Apr 2026 17:03:21 +0800 Date: Tue, 28 Apr 2026 17:03:20 +0800 From: Feng Tang To: "David Hildenbrand (Arm)" Cc: Marek Szyprowski , Robin Murphy , Ying Huang , Andrew Morton , Lorenzo Stoakes , Liam.Howlett@oracle.com, Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-mm@kvack.org, Christoph Hellwig , Catalin Marinas , Will Deacon , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Changrong Chen Subject: Re: [PATCH v3] dma-contiguous: setup default numa cma area if not configured explicitly Message-ID: References: <20260428060550.7167-1-feng.tang@linux.alibaba.com> <6dd52f8b-7092-4d02-ba24-f8b55409b7b6@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=utf-8 Content-Disposition: inline In-Reply-To: On Tue, Apr 28, 2026 at 04:37:08PM +0800, Feng Tang wrote: > > > include/linux/cma.h | 1 + > > > kernel/dma/contiguous.c | 14 ++++++++++++-- > > > mm/cma.c | 11 ++++++++++- > > > 3 files changed, 23 insertions(+), 3 deletions(-) > [...] > > > +extern int cma_get_nid(const struct cma *cma) > > > +{ > > > + return cma->nid; > > > +} > > > > Why do you have to store the nid instead of just looking it up from the base_pfn > > in here? > > My thought was 'struct cma' already have 'nid' member, and when CONFIG_NUMA=y, > it may be useful to save the 'nid' info instead of NUMA_NO_NODE for the default > cma area (cmdline like cma=XXG@YYG could make it on different node) One interesting thing is about the API to get nid, I initially worked on 6.19 base, and used 'pfn_to_nid()' which worked well, but I got a kernel panic when rebasing to 7.1. It turned out, latest kernel changed the order of default cma reserving to before the initialization 'struct page' (only tested on arm64), and pfn_to_page() will return NULL at the reserving time, so I changed to early_pfn_to_nid(). Storing the 'nid' could save the logic of chosing the right API in cma_get_nid(). Thanks, Feng