From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 5C33C32BF24 for ; Wed, 10 Dec 2025 20:23:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765398190; cv=none; b=MOJBLOLByJu4nB9YiYg1a7L8Yw4TweOhIbanaBsF6o/P3/LvRIIvf6jaFYhFktuJhN4f7obKnl3iUezZOtG4EgMKgozGcdLk5HvppIT95h0hKOdyHgXHHQdmyps3xcUbVPB2vrBY5Qu1kFQPhUeiKbl3HP6Fux9uCVE7rNpytW4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765398190; c=relaxed/simple; bh=4biQEPINOrg4CKxgMwHCUpM+UC2ZDmzxUgjLbt2N7cU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dhwP1Sfy8fMEc+Vg1nATvYbawlKpOHnXQLfMrT9iKicv3wxJeLP8gB/RgodX5bzVdLqmhCj0P4oRieo37najJqbTIRAaCX7b4uCNi7+cWdbVrVv+VA0hcNxJo4aSiXiyCRo7Z/3AejmiXMYrvZyCao3KXg8WDiRfAXChpMxgMpo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=aLccRR9O; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=dq/Eh4uW; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="aLccRR9O"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="dq/Eh4uW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765398187; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qCVxcy9QRWz5ZYAmOizCoYj4D+NmiFdOKdb5vzD8rtA=; b=aLccRR9O0SXJmPiK07lkp17ZD4ozBJn3olWVia4YDYFNtqfb1OvMw3L2OxysHc7aiXay7f NSd1C8pLjyNT09TLPFZDjaKCkJTakLL8Tj4jjtZsQDOZr19GlEkzv0TUR9BurHBLBfz/nd 5aDRwUkCZes5k7X/NtPr313HP/GpzQM= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-479-xNLiGGXaOyGq2yhw6Jhwzg-1; Wed, 10 Dec 2025 15:23:05 -0500 X-MC-Unique: xNLiGGXaOyGq2yhw6Jhwzg-1 X-Mimecast-MFC-AGG-ID: xNLiGGXaOyGq2yhw6Jhwzg_1765398184 Received: by mail-qv1-f72.google.com with SMTP id 6a1803df08f44-8823a371984so4771146d6.1 for ; Wed, 10 Dec 2025 12:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1765398184; x=1766002984; 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=qCVxcy9QRWz5ZYAmOizCoYj4D+NmiFdOKdb5vzD8rtA=; b=dq/Eh4uWIeu8k7J92gSKsn+3ssZYXV3VDFFy+jM8Xi7mN+Pbhdl2aoRw6UaSuOw31U C63f6bhL8SgEs8xTNF54ag7tXx6m+jpR8jsDcs0pm6G9oWPANYU9GKtzv94FAhw5l5/m F1fMfKHPOnaIL1yEFong0yDL24eh2N7JCzAiZhwskczan4FwamKY3eLOItoWaj7PQx8b lV+Xn9OF5eyclq9zlY+yINnHki++3xkWCTurrIAb/V1LJ/n0Qas/YLY48LV0DvrCtmUj NgRnyf2aY381MswiiwDZHf6SH831jz18m8vDn4qcerfEa+RJxoVJuoWEW3BiCickGTWJ uj0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765398184; x=1766002984; 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=qCVxcy9QRWz5ZYAmOizCoYj4D+NmiFdOKdb5vzD8rtA=; b=T7qzNRxUhFh16EHTwx2IFALM+1aKu6hfc+CYM8ShtGqc2UODQ/kqP+dLI8oyvhL7bS X/hvufVICYRvxrmiFcmWlSBdXjaiimnwu9GDy61edD27/wUjHNP+/XezUN+TQDoF/soh Pg8l7ImZ3Q8Erl5mmFlT6Uj4JmANzAGrv0Oq6y8iCpguQObczaglnDU1GbvjT+1XcTYi ZUowbGNJuse5vgZYwD/GIRjEXlnjLdlFSm6IW1xuv8KH0vEGp1h4Qtnz4SpXrKmppFox 9U97JICB5ohrLTwLBKNCBQK+E4rFMUF0wEbC+dMoxRE7w68bNMbjvo3jqM/J2Ga6+ILu zfLw== X-Forwarded-Encrypted: i=1; AJvYcCWTJ9a9jToJL/llEyqFAUYESYMQ5l08gI10XCUFdegxat1pWoxUrv9QcD11eK7CWbdmD0c5OQ/iGkjrFQ4=@vger.kernel.org X-Gm-Message-State: AOJu0YxTP8Mqi5mlDsA6Wzdn/0G5KmeTquZ6JqDHAtdUzNS6i/X7Yl6N ZKyftoPp1arzdPJPFMEBPbmmBb1+0caNtUIX3lO2Cn6CYob8kIP1eQDzG15VWh9D1kvtanxd5rT AyqlQRgZn42k9HMMgscKfeZwcU7Md9MgiZ5aO7ydR9BujFq6ahQG53WGfdU3mrGWIwg== X-Gm-Gg: AY/fxX4pdoPsy+uWiopKtD1N1m0CbFmLhf2NxOnnF7PM5x09RlUuuFIt3wt7JmueUBu CZ+9RuDrYEpbnKRIsQEivG8BUZb8Hs+5N53W1TpMhQheeoZZYfT9f2OG4lY8cuia5jcVf8r3kbi Q0GAPJ29VPZRnpnttYgaP63a3pSJh9BrV9pPzTSC3wlEuUliEveGZAXss85Ob/251pXBxRWY2ua y7lxp11N6Thc2l9AWQNjwKjXp1ZDHvu4yRZFdJcQgRi6IiHH/2YZqLS0wNoDI7Oyu/FbQyOAP/v jYDeht7kSmvkkdYPLHv63xIxSfQSVf/GEkLTKatT9zuo+Kd69y+CR1clNHYT3GawIJeGAyVIgsO p/Os= X-Received: by 2002:a05:6214:4903:b0:87d:e32:81c4 with SMTP id 6a1803df08f44-88863ad08cemr52863366d6.48.1765398184391; Wed, 10 Dec 2025 12:23:04 -0800 (PST) X-Google-Smtp-Source: AGHT+IEen9Ttl4I4Ei6GHZ1MxrJ25bb6YcCEXyK7UMXPPB/FWpCm+gy8UvSEyxIjsONMA4wz0hEVYw== X-Received: by 2002:a05:6214:4903:b0:87d:e32:81c4 with SMTP id 6a1803df08f44-88863ad08cemr52862896d6.48.1765398183866; Wed, 10 Dec 2025 12:23:03 -0800 (PST) Received: from x1.local ([142.188.210.156]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8886ec567dfsm5133986d6.22.2025.12.10.12.23.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Dec 2025 12:23:03 -0800 (PST) Date: Wed, 10 Dec 2025 15:23:02 -0500 From: Peter Xu To: Jason Gunthorpe Cc: kvm@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nico Pache , Zi Yan , Alex Mastro , David Hildenbrand , Alex Williamson , Zhi Wang , David Laight , Yi Liu , Ankit Agrawal , Kevin Tian , Andrew Morton Subject: Re: [PATCH v2 2/4] mm: Add file_operations.get_mapping_order() Message-ID: References: <20251204151003.171039-1-peterx@redhat.com> <20251204151003.171039-3-peterx@redhat.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=utf-8 Content-Disposition: inline In-Reply-To: On Sun, Dec 07, 2025 at 12:21:32PM -0400, Jason Gunthorpe wrote: > On Thu, Dec 04, 2025 at 10:10:01AM -0500, Peter Xu wrote: > > Add one new file operation, get_mapping_order(). It can be used by file > > backends to report mapping order hints. > > > > By default, Linux assumed we will map in PAGE_SIZE chunks. With this hint, > > the driver can report the possibility of mapping chunks that are larger > > than PAGE_SIZE. Then, the VA allocator will try to use that as alignment > > when allocating the VA ranges. > > > > This is useful because when chunks to be mapped are larger than PAGE_SIZE, > > VA alignment matters and it needs to be aligned with the size of the chunk > > to be mapped. > > > > Said that, no matter what is the alignment used for the VA allocation, the > > driver can still decide which size to map the chunks. It is also not an > > issue if it keeps mapping in PAGE_SIZE. > > > > get_mapping_order() is defined to take three parameters. Besides the 1st > > parameter which will be the file object pointer, the 2nd + 3rd parameters > > being the pgoff + size of the mmap() request. Its retval is defined as the > > order, which must be non-negative to enable the alignment. When zero is > > returned, it should behave like when the hint is not provided, IOW, > > alignment will still be PAGE_SIZE. > > This should explain how it works when the incoming pgoff is not > aligned.. Hmm, I thought the charm of this new proposal (based on suggestions of your v1 reviews) is to not need to worry on this.. Or maybe you meant I should add some doc comments in the commit message? If so I can do that. thp_get_unmapped_area_vmflags() should have taken all kinds of pgoff unalignment into account. It's just that this v2 is better than v1 when using this new API because that THP function doesn't need to be exported anymore. > > I think for dpdk we want to support mapping around the MSI hole so > something like > > pgoff 0 -> 2M > skip 4k > 2m + 4k -> 64M > > Should setup the last VMA to align to 2M + 4k so the first PMD is > fragmented to 4k pages but the remaning part is 2M sized or better. > > We just noticed a bug very similer to this in qemu around it's manual > alignment scheme where it would de-align things around the MSI window > and spoil the PMDs. Right, IIUC this series should work all fine exactly as you said. Here the driver should only care about what owns the content of (pgoff, len) range, and the proper order to map these chunks. In case of VFIO, it will know what BAR it's mapping, so as to return a proper order for that specific bar pointed by (pgoff, len). The driver doesn't need to worry on anything else like above. Let me know if I misread your question, or if this series doesn't achieve what you're asking here.. Thanks, > > I guess ideally the file could return the order assuming an aligned-to-start > pgoff and the core code could use that order to compute an adjustment > for > the actual pgoff so we maintain: > va % order = pgoff % order > > Jason > -- Peter Xu