对于正在使用(...still必须使用)32位二进制文件的系统来说,这是一个有用的特性,并且考虑到了4G限制。
这实际上意味着,32位用户空间代码、32位用户空间数据和(32位PAE,或64位)内核生活在不同的地址空间中,这基本上使进程能够使用几乎所有可能的最大4G地址空间。
除了一些古代公告之外,不幸的是,我再也找不到它了:
我很高兴地宣布首次公开发布2.5.74 Linux内核的"4GB/4GB VM拆分“修补程序:http://redhat.com/~mingo/4g-patches/4g-2.5.74-F8 4G/4G拆分功能主要用于大型RAM x86系统,这些系统希望(或必须)获得更多的内核/用户VM,而代价是每-syscall TLB-刷新开销。在x86上,虚拟内存总量--我们都知道--仅限于4GB。在总共4GB的VM中,用户空间使用3GB (0x000000-0xbfffff),内核使用1GB (0xc000000-0xffffff)。这就是VM方案被称为3/1分裂。这种分割直到1GB的RAM才能很好地工作--即使在那之后,它也能很好地工作,这是因为“highmem”,它将各种较大的缓存(和对象)移动到高内存区域。
在我的测试中,我的一些进程开始以2-3 GB的速度死亡。
我怎样才能做到这一点?我使用了一个相对最近的内核(4.10)。我可以在32位用户空间上使用64位内核,也可以使用32位PAE内核。
如果只有一些进程使用4G/4G,这就足够了,但他们似乎真的需要它。
发布于 2018-01-20 22:29:41
在64位内核上,您已经可以通过32位用户空间程序访问完整的4G。请参见在终端中输入以下内容(警告:如果系统运行时没有可用的4 4GiB,系统可能会失去响应):
cd /tmp
cat > test.c <<"EOF"
#include <stdlib.h>
#include <stdio.h>
int main()
{
size_t allocated=0;
while(1)
{
const size_t chunkSize=4096;
char* p=malloc(chunkSize);
if(!p) return 0;
*p=1;
allocated+=chunkSize;
printf("%zu\n",allocated);
}
return 0;
}
EOF
gcc test.c -o test -m32 && ./test | tail -n1在我的x86_64内核3.12.18上,我得到了4282097664,它大约是4GiB-12.3MiB,所以考虑4G/xG拆分是公平的。
https://unix.stackexchange.com/questions/388156
复制相似问题