From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) (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 95B49338939 for ; Wed, 7 Jan 2026 20:24:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.195 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767817468; cv=none; b=UeLE3TedNwAH3q0fv3HySc/I3Yfp7kiiCKq0eOW74mh8xntjyPO1M2xl7ImaASMmAtM3LNV/qbe3YbC4NYZVT9Op9xzIImkbxdwcJLhCj3iYLbmD3KO0AWeHP3LOmwolNkfwGmRl8iTgfE6Ujjf3LDOu4oDsI62wqb9W20s/I3A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767817468; c=relaxed/simple; bh=/u8/mdCRbNm8MvpUWRoGYHAWAojzapM2ntHzieeqBkA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sZCOU6NNUxE76V1ZVuNg64hkRHxFTJ2FtkDqW2A8EjOhOlTt+B+WFHzRsRu2FHDuoKxFfZKWNbuGHJTUUvfw1KamLsBHq8Amxsk4iMgkkSU+XmLRZ/b3HWqYPSCvB4OWmWP58xXO69GOSjffyWIMywUamFEctutk8aiExFXkkeo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=SVfBwqXm; arc=none smtp.client-ip=209.85.222.195 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="SVfBwqXm" Received: by mail-qk1-f195.google.com with SMTP id af79cd13be357-8b31a665ba5so283519585a.2 for ; Wed, 07 Jan 2026 12:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1767817465; x=1768422265; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=/u8/mdCRbNm8MvpUWRoGYHAWAojzapM2ntHzieeqBkA=; b=SVfBwqXmo9INeGgwj8+M0QkR0kNN1fKIykr9WSqmGV97J21rTBh1doiTFP43DmwM/N 64PCjXzq7dBIAjkMSpLR8fiLoAkZ1mJFxCzRdmxaFKOZ8vsjOrk9Kgy7K0sqw9EkG70q fkPCBQILucR/MAzILD0SqD1+hNvFdtGEI9eysTxGy8o6Lxfz+yZrLg+LK0tivmJ8ZeKw ZSy7naOr+y70hGcYOTvm2r5Wfn0BHjm4SFrl1Xh5fHd1bpZBwTzyHqJTH7sBhQuC5W72 yMajX7cu4+aPdGWhDgzWKKp+vOf15oz7KRyQxFLEVNhycs8UIBdgIvpMzvV/IQEQ7FmY jWag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767817465; x=1768422265; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/u8/mdCRbNm8MvpUWRoGYHAWAojzapM2ntHzieeqBkA=; b=cOogk1xGwl+6aSApYIY4FdS1VMUBwn+NFg7VRcpP7zzAmBJewTlsVChCPlW6r7x0Kg mIDj8nnGsnOc7rtqB5oX+iHZLf9NdTZ3HH6ufoR0r9bERoRPIba3IiYMJXVl/t/rMVvx ripYSEDE3vTvWSDwh+ixuAgy0jrmRAxb/dRvTKcvf8KHtiAXKY9DyO8jVYnNk+14r1Tw nWkDel/1fOsj4h4swcQOuZh+nOXHY4mRRaSI5ntIb1hPAsp+5sddTAYnlQKw2llHXuPB +eLxu1y2XMeM5/vVwGQyWqOXjdOVXnaY2zjkYyMQ4LhdF1bCl3soH5whgbxX9KS8uP5+ ryOQ== X-Forwarded-Encrypted: i=1; AJvYcCUwPBVb+PiIJxxO6zBAFSvaf6OGlPDKxN9UwSue5tj/oDRkW90SVh5ggC4tG1MafxYdaAkrugE7WFzXlu8=@vger.kernel.org X-Gm-Message-State: AOJu0YxD11J9EDksRqtMZk5G0CauS6fCMslXE/aQ0Du0ZKwyADddN8Eh 6hDyPHQ4CcuY6iBzjR6UNlWsmnfCdzkj3JEZUQGV+VFv1dF5n3itXTZAlbEVqCiS2w0= X-Gm-Gg: AY/fxX7CAi1sYEgAvBM+1iFGml9wI6jik4oeocg45v8Df/sZ8EUHjCHiqchQFtD5PES crtea2PL1s6rbp7rExwuGPOO3z6Mi0hH+e8QtrAFN/vLklFQVJWPHuu0d5pvlpC74udd0I1TRSH 1uvjC8V7j8o92Ps8M4uJbQYwbXEYYbh68+DcTwgpkpDQK3UG+f9FhK+5DAW85CnPPeF0RDgl1ia dnhxDf9rZUxOV+tEtZDfTPZpxrfhZcqWMnkOZ55jr+PWVWUc+XV1yEvB6Qzqv9MkJQMVduJa+7b fjhdj+uLW3YKnnmtMu7CUTnmsYOxJL+6b8a+ard+Zc3ISGqXW8HuzYFc9ryGU74jg8p7liIJT5m 9iY40t0/f4OIMLt58xkxwefNpzMU4LZf2g0lgCSk9K9dKm5856Fz4Yg+lfqrZJ/myJuNooBKbIR PKeN6igwaLeFd5020/AGKW+cqCqxOQJf+I2zyDeaLUXJ4N0AT+FnOyMS2vICP/S2j1OYU= X-Google-Smtp-Source: AGHT+IFkPMUDNbhV7qApG1EaAD4bH67XKeWGZyq9t6Oa6ftUcT4ea6J2MjhLCsI7jETaTx/wz1BYtw== X-Received: by 2002:a05:620a:2681:b0:8b2:e669:987e with SMTP id af79cd13be357-8c3893dcc02mr421767485a.46.1767817465357; Wed, 07 Jan 2026 12:24:25 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-112-119.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.112.119]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c37f51ceb5sm470433485a.35.2026.01.07.12.24.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 12:24:24 -0800 (PST) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1vda4u-00000002F6i-0YUA; Wed, 07 Jan 2026 16:24:24 -0400 Date: Wed, 7 Jan 2026 16:24:24 -0400 From: Jason Gunthorpe To: Logan Gunthorpe Cc: Hou Tao , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-nvme@lists.infradead.org, Bjorn Helgaas , Alistair Popple , Leon Romanovsky , Greg Kroah-Hartman , Tejun Heo , "Rafael J . Wysocki" , Danilo Krummrich , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , Keith Busch , Jens Axboe , Christoph Hellwig , Sagi Grimberg , houtao1@huawei.com Subject: Re: [PATCH 10/13] PCI/P2PDMA: support compound page in p2pmem_alloc_mmap() Message-ID: <20260107202424.GC340082@ziepe.ca> References: <20251220040446.274991-1-houtao@huaweicloud.com> <20251220040446.274991-11-houtao@huaweicloud.com> <07a785e5-5d2e-4c81-a834-1237c79fdd51@deltatee.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <07a785e5-5d2e-4c81-a834-1237c79fdd51@deltatee.com> On Mon, Dec 22, 2025 at 10:04:17AM -0700, Logan Gunthorpe wrote: > I would have expected this code to allocate an appropriately aligned > block of the p2p memory based on the requirements of the current > mapping, not based on alignment requirements established when the device > is probed. Yeah, I think this is not right too. I think the flow has become confused by trying to set a static vmemmap_shift when creating the pgmap. That is not how something like this should work at all. Instead the basic idea should be that each mmap systemcall will determine what folio order it would like to have, it will allocate an aligned range of physical from the genpool, and then it will alter the folios in that range into a single high order folio. Finally the high order folio is installed in one shot with the mm dealing with placing it optimally in the right page table levels. You could use a heuristic (ie I'm 2M size aligned or 1G size aligned) or maybe use the MAP_HUGE_2M/MAP_HUGE_1G flags, or something else perhaps. Don't follow what DAX did, this doesn't have the limitations DAX had to work with. I also don't think drivers should be open coding the vm_insert_folio_xx() stuff, the mm should have a helper to accept a folio of any order, the VA and the phys, then install it optimally. So don't export vm_insert_folio_pmd()/etc please. Finally, Peter Xu has been working on the issue of setting the alignment of VMAs when they will be used to hold large aligned folios, that would help this be more useful by avoiding the need for MAP_FIXED: https://lore.kernel.org/kvm/20251204151003.171039-1-peterx@redhat.com/ Assuming the folio size can be determined early enough in the VMA process, though Lorenzo's recent refactorying here into mmap_prepare may be helpful. Jason