On Wed, Aug 23, 2023 at 7:25 AM Jakub Kicinski [off-list ref] wrote:

On Wed, 23 Aug 2023 11:03:31 +0800 Yunsheng Lin wrote:

quoted

On 2023/8/22 23:38, Jakub Kicinski wrote:

quoted

On Tue, 22 Aug 2023 17:21:35 +0800 Yunsheng Lin wrote:

quoted

As the CONFIG_PHYS_ADDR_T_64BIT seems to used widely in x86/arm/mips/powerpc,
I am not sure if we can really make the above assumption.

https://elixir.free-electrons.com/linux/v6.4-rc6/K/ident/CONFIG_PHYS_ADDR_T_64BIT

Huh, it's actually used a lot less than I anticipated!

None of the x86/arm/mips/powerpc systems matter IMHO - the only _real_

Is there any particular reason that you think that the above systems does
not really matter?

Not the systems themselves but the combination of a 32b arch with
an address space >16TB. All those arches have 64b equivalent, seems
logical to use the 64b version for a system with a large address space.
If we're talking about a system which ends up running Linux.

quoted

As we have made a similar wrong assumption about those arches before, I am
really trying to be more cautious about it.

I searched through the web, some seems to be claiming that "32-bits is DEAD",
I am not sure if there is some common agreement among the kernel community,
is there any previous discussion about that?

My suspicion/claim is that 32 + PAGE_SHIFT should be enough bits for
any 32b platform.

One additional thing we could consider would be to simply look at
having page_pool enforce a DMA mask for the device to address any
cases where we might not be able to fit the address. Then in the
unlikely event that somebody is running a 32b system with over 16
terabytes of RAM. With that the DMA subsystem would handle it for us
and we wouldn't have to worry so much about it.