H2o: h2o_buffer_reserve()에 MAP_SHARED가 필요한 이유

액세스할 다른 프로세스가 있습니까? 그렇지 않은 경우 MAP_PRIVATE를 설정하지 않는 이유

mktemps + fallocate + mmap을 사용하는 목적은 데이터 버퍼링에 사용할 수 있는 최대 공간이 swap_ 대신 _디스크의 여유 공간에 의해 제한되도록 파일 지원 버퍼를 만드는 것입니다. MAP_PRIVATE 이 목표와 충돌합니다.

또한 mremap을 지원하는 플랫폼에서 mmap(2) 및 munmap(2) 대신 mremap(2)을 사용할 수 있습니까?

추가된 페이지가 익명이 아니라는 가정 하에 가능합니다. 또한 mremap 사용하여 성능이 눈에 띄게 변경되면 매핑된 페이지를 매핑 해제(영구적으로 또는 다시 매핑의 일부로)한 후 페이지가 이동될 가능성을 최소화하는 방법을 알아야 합니다. 가장 비용이 많이 드는 작업입니다. 그리고 이것이 반드시 mremap 사용해야 한다는 의미는 아닙니다.

어쨌든 많은 양의 데이터를 버퍼링하는 것은 부차적인 전략이며 성능 향상에 노력을 기울이는 것은 좋지 않다고 생각합니다. 프록시 처리기 이외의 처리기에 스트리밍 요청(#1357 참조)을 채택하는 작업을 선호합니다.

buffering large amount of data is a secondary strategy 가 포인트입니다.
프로그램이 mktemps + fallocate + mmap 거의 빠지지 않는다고 추측하십시오.

큰 버퍼가 필요하지 않은 핸들러에서 처리하는 스트리밍 요청, 맞습니까?

제 생각에는 공유 또는 비공개 mmap 리소스(임시 업로드 자리 표시자일지라도)를 사용하는 것은 나쁜 생각입니다. $TMP 또는 $TMPDIR 위치는 사용자 환경의 모든 것이 될 수 있으며, 예를 들어 HDD가 될 수 있습니다. 관리자가 기억해야 하는 추가 단계일 뿐입니다. $TMP가 ramdisk 마운트인 경우 대용량 파일의 동시 업로드는 메모리 압력을 쉽게 생성할 수 있다는 것은 말할 것도 없습니다.

비 프록시 처리기로 스트리밍 요청 작업을 수행하는 데 있어 귀하의 제안과 방향이 매우 마음에 듭니다. 기대하고 테스트할 준비가 되었습니다!