The Linux Kernel Is Preparing To Enable 5-Level Paging By Default

[Setif]

I probably don't understand how OS paging works here, but why do we need to increase from 256 TiB limit, when today, Xeon can only do 768 GiB and EPYC can do 2 TiB per socket? How are we in jeopardy of hitting this 256 TiB limit today or in the near future?

Intel Xeon Platinum support 4.5TiB of RAM see https://ark.intel.com/content/www/us...-2-70-ghz.html

[GrayShade]

Are there any CPUs that support this besides QEMU?

[abott]

I probably don't understand how OS paging works here, but why do we need to increase from 256 TiB limit, when today, Xeon can only do 768 GiB and EPYC can do 2 TiB per socket? How are we in jeopardy of hitting this 256 TiB limit today or in the near future?

Servers can use non-RAM storage as RAM cache. That alone is a reason to increase it to as large as is possible at any given time.

[chithanh]

On the surface this sounds like absolute insanity. We are talking about 64 bit processors here, why would you need more than two levels of paging. Maybe I’m missing something (totally possible) but with the two address ranges, virtual and hardware it would seem like the goal should have been to reduce the number of paving levels.

This is makes me wonder how this impacts ARM and Power. Makes me wonder if there is a good web site that goes into comparing addressing in the physical and virtual worlds for these processors.

You REALLY should google what paging is for.

Issue that 64 bit space is so huge that if you try to map it directly our with only few levels page table itself will eat up all your memory and much more.

Actually, the comment on Power was on the mark. PowerPC uses hash-table paging so does not need to introduce a new translation layer just because that much memory could exist in a system.

[Space Heater]

How are we in jeopardy of hitting this 256 TiB limit today or in the near future?

From the documentation on 5-level paging:

Original x86-64 was limited by 4-level paing to 256 TiB of virtual address space and 64 TiB of physical address space. We are already bumping into this limit: some vendors offers servers with 64 TiB of memory today.

[torsionbar28]

Data is getting bigger and bigger. Some servers have Terabytes of RAM.

I probably don't understand how OS paging works here, but why do we need to increase from 256 TiB limit, when today, Xeon can only do 768 GiB and EPYC can do 2 TiB per socket? How are we in jeopardy of hitting this 256 TiB limit today or in the near future?

[ThoreauHD]

This also smells like Zen 3 hbm/3D die stacking prep to me.

[Space Heater]

[insert xkcd joke]

Ah yes, the joke where people simultaneously think that core kernel scalability work is unimportant/not used, and that linux kernel developers had any role in Adobe flash support.

On the surface this sounds like absolute insanity. We are talking about 64 bit processors here, why would you need more than two levels of paging.

So you're not going to even bother searching online as to why operating systems have multiple levels of paging, and instead you're going to assume that the kernel developers are simply misguided or insane?

[pkunk]

We are talking about 64 bit processors here, why would you need more than two levels of paging. Maybe I’m missing something (totally possible) but with the two address ranges, virtual and hardware it would seem like the goal should have been to reduce the number of paving levels.

Issue that 64 bit space is so huge that if you try to map it directly our with only few levels page table itself will eat up all your memory and much more.

[johannesburgel]

We are talking about 64 bit processors here, why would you need more than two levels of paging. Maybe I’m missing something (totally possible) but with the two address ranges, virtual and hardware it would seem like the goal should have been to reduce the number of paving levels.

You REALLY should google what paging is for.