리눅스 커널의 메모리 제한

난처한 문제가 있습니다. 사용자 정의 CDB를 실행하기 위해 sg 를 사용하는 라이브러리가 있습니다. sg의 메모리 할당에 문제가있는 시스템이 몇 가지 있습니다 . 일반적으로 sg 드라이버는 약 4mb의 하드 한계를 갖지만 ~ 2.3mb 요청이있는 몇 가지 시스템에서 볼 수 있습니다. 즉, CDB는 2.3mb 전송을 할당 할 준비를하고 있습니다. 여기에는 아무런 문제가 없어야합니다 : 2.3 <4.0.

이제 기계의 프로파일입니다. 64 비트 CPU이지만 CentOS 6.0 32 비트를 실행합니다 (빌드하지 않았 으며이 결정과 관련이 없습니다). 이 CentOS 배포판의 커널 버전은 2.6.32입니다. 그들은 16 기가 바이트의 RAM이 있습니다.

다음은 시스템에서 메모리 사용량이 어떻게 보이는지입니다 (자동 테스트 중에이 오류가 발생하기 때문에이 오류가 sg 에서 반환 된 상태를 반영하는지 여부는 아직 확인되지 않았습니다 ).

top - 00:54:46 up 5 days, 22:05,  1 user,  load average: 0.00, 0.01, 0.21
Tasks: 297 total,   1 running, 296 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  15888480k total,  9460408k used,  6428072k free,   258280k buffers
Swap:  4194296k total,        0k used,  4194296k free,  8497424k cached

커널에 메모리를 할당하는 것에 관한 Linux Journal 에서이 기사 를 찾았습니다 . 이 기사는 날짜가 있지만 2.6과 관련이있는 것 같습니다 (머리에 저자에 대한 의견). 이 기사는 커널이 약 1GB의 메모리로 제한되어 있다고 언급합니다 (물리적 또는 가상 또는 전체에 대해 1GB가 텍스트라면 완전히 명확하지는 않지만). 이것이 2.6.32에 대한 정확한 진술인지 궁금합니다. 궁극적으로 이러한 시스템이이 한계에 도달하는지 궁금합니다.

이것이 실제로 내 문제에 대한 답변은 아니지만 2.6.32에 대한 주장의 진실성에 대해 궁금합니다. 그렇다면 커널의 실제 메모리 제한은 얼마입니까? 문제 해결을 위해 고려해야 할 수도 있습니다. 다른 제안은 환영합니다. 이것이 당황스럽게 만드는 이유는 이러한 시스템이 동일한 문제를 나타내지 않는 다른 시스템과 동일하다는 것입니다.

32 비트 시스템에서 Linux 커널 메모리에 대한 1GiB 제한은 32 비트 주소 지정의 결과이며 매우 엄격한 제한입니다. 변경이 불가능하지는 않지만 아주 좋은 이유가 있습니다. 변경하면 결과가 발생합니다.

리눅스가 만들어 졌던 1990 년대 초반에 기계를 가져가 보자. 당시에는 Linux를 2MiB의 RAM에서 실행할 수 있는지 또는 실제로 4 개의 전체 MiB가 필요한지 에 대한 논쟁이있었습니다 . 물론, 16 개의 MiB 몬스터 서버와 함께 하이 엔드 snob이 모두 우리에게 몰려 들었습니다.

재미있는 작은 소품은 무엇과 관련이 있습니까? 그 세계에서는 간단한 32 비트 주소 지정에서 얻은 4GiB 주소 공간을 어떻게 나누는 지에 대한 결정을 쉽게 내릴 수 있습니다. 일부 운영체제는 단지 "커널 플래그"로 주소의 상위 비트를 치료, 반으로 분할 : 주소 0 2 ³¹ -1 상단 비트, 삭제 및 사용자 공간 코드를했다 있었고, 주소 2 ⁽³¹⁾ (2)를 통해 ³² - 1은 최상위 비트를 설정했으며 커널을위한 것입니다. 주소를보고 말할 수 있습니다 : 0x80000000 이상, 커널 공간이고 그렇지 않으면 사용자 공간입니다.

PC 메모리 크기가 4GiB 메모리 제한으로 확대되면서이 간단한 2/2 분할이 문제가되기 시작했습니다. 사용자 공간과 커널 공간은 모두 많은 RAM에 대한 좋은 주장을 가지고 있었지만 컴퓨터를 사용하는 목적은 일반적으로 커널을 실행하기보다는 사용자 프로그램을 실행하는 것이기 때문에 OS는 사용자 / 커널 분할을 가지고 놀기 시작했습니다. 3/1 분할은 일반적인 절충안입니다.

실제 대 가상에 대한 귀하의 질문에 대해서는 실제로 중요하지 않습니다. 기술적으로 말하자면 가상 메모리 제한이지만 Linux가 VM 기반 OS이기 때문입니다. 32GiB의 물리적 RAM을 설치해도 아무런 변화가 없으며 swapon32GiB 스왑 파티션에 도움이되지 않습니다 . 어떤 작업을하든 32 비트 Linux 커널은 동시에 4GiB 이상을 처리 할 수 ​​없습니다.

(예, PAE 에 대해 알고 있습니다. 이제 64 비트 OS가 마침내 인수되고 있으므로, 우리는 그 불쾌한 핵을 잊어 버리기를 희망합니다.

결론은 1 GiB 커널 VM 한계에 도달하면 2/2 분할로 커널을 다시 빌드 할 수 있지만 이는 사용자 공간 프로그램에 직접적인 영향을 미친다는 것입니다.

64 비트가 정답입니다.

나는 그가 쓰는 것보다 실제로 상황이 좋지 않기 때문에 워렌 영의 훌륭한 대답에 약간을 추가하고 싶습니다 .

1GB 커널 주소 공간은 두 부분으로 나뉩니다. 128MB는 vmalloc이고 896MB는 lowmem입니다. 그것이 실제로 무엇을 의미하는지 신경 쓰지 마십시오. 메모리를 할당 할 때 커널 코드는 원하는 것을 선택해야합니다. 사용 가능한 공간이있는 풀에서 메모리를 얻을 수 없습니다.

을 선택 vmalloc하면 128MB로 제한됩니다. 이제 1GB는 그렇게 나쁘지 않습니다 ...

을 선택 lowmem하면 896MB로 제한됩니다. 1GB에서 멀지 않은이 경우 모든 할당은 다음 2의 제곱으로 올림됩니다. 따라서 2.3MB 할당은 실제로 4MB를 소비합니다. 또한을 사용할 때 한 번의 호출에서 4MB 이상을 할당 할 수 없습니다 lowmem.

64 비트가 정답입니다.