libc가 홀딩하고 있는 free 메모리를 시스템에 반납할 수 있는 방법이 있나요?

왜 free memory 에 집착하시는지 잘 이해가 안 갑니다.
현재 OS 들은 Virtual Memory 를 이용하고 swap 영역을 이용하고 있기 때문에, A process 가 1G memory 를 사용하고 있다고 해서 실제 physical memory 를 1G 사용하고 있다고 할 수는 없습니다.
따라서 이미 반납한 memory 라면 별로 신경 안 쓰셔도 됩니다.
물론 처음에 swap 영역 할당하고 하는데 조금 시간이 더 걸릴 수는 있습니다. 하지만 저 영역을 다 OS 에게 반납했다 하더라도, 다음번에 다시 memory 를 요청하면 다시 OS 에서 VM 을 할당하고 하는 overhead 도 무시할 수 없습니다.
즉 A process 가 일시적으로 memory를 무진장 사용해 2G를 사용했다가 다 반납하고 현재는 100M 만 있으면 된다. 그리고 앞으로 두번다시 memory 사용량이 올라갈 일이 없다. 라면 가급적 남은 memory 영역을 OS 에게 반납하는 것이 좋겠습니다만, 그렇지 않다면 굳이 반납하게 만들 필요가 없어 보입니다.

그리고, 대부분의 malloc 계열 library 들은 heap 을 할당받기 위해 (s)brk 를 사용합니다. 이 API 는 manual 을 참조해 보시면 아시겠지만, 선형적으로 증가 or 감소합니다. 이 이야기는 특정 영역 부분만 OS 에게 반납할 방법이 없다! 라는 것을 의미합니다. 그리고 일부(?) malloc manual 을 잘 보시면, 사용자가 직접 (s)brk 를 사용하는 것에 대해서 나오는 것도 있습니다. 이런 것들을 잘 읽어 보시면 (s)brk 로 새 영역을 받아오는 것은 허용하지만, 줄이는 것은 안된다고 나옵니다. 이는 malloc 이 (s)brk 로 받은 영역을 반납하는 경우는 없다는 것을 반증(?)하는 것이지요.

뭐 이야기가 조금 딴데로 샜습니다. 여튼 저런 것을 정 피하고자 하신다면, 별도의 malloc 함수를 사용하시면 될 듯 합니다. glibc 에서 사용한 doug lea의 malloc 등을 조금 손봐, (s)brk 대신 mmap 을 이용하여 heap 을 할당하도록 바꾸시면 됩니다. 물론 free 된 영역은 munmap 을 이용하여 반납하도록 만드셔야 겠지요. 하지만 이 방식의 단점은 위에도 적었지만, (s)brk 방식보다 매우 느립니다! mmap/munmap 이 상대적으로 느린 것도 있을 테고, 상대적으로 (s)brk 보다 더 자주 불려야 한다는 점도 있을 것입니다. 만약 해당 process 가 최대 얼만큼 memory 를 사용하게 될 지 미리 안 다면 비교적 간단하게 할 수 있을 듯 합니다. (미리 그보다 큰 영역을 mmap 으로 할당받은 뒤 그 영역을 doug lea 의 malloc 을 이용하여 할당해주거나 반납하게 하고, 모든 작업이 완료되면 한번에 munmap 으로 반납하게 만들어 주면 됩니다. mmap/munmap 의 회수도 매우 줄어 성능저하도 거의 없을 것입니다.)

ps. 실제로 제가 저 짓을 했습니다. 제 경우는 다른 process 때문이라기 보다는, 사용한 program 이 서버형식이라 관리자가 신경질적으로 사용 memory 를 모니터링 하면서 태클을 걸어 어쩔 수가 없었던 경우였습니다. ㅠ.ㅠ