free명령을 통해서 나오는 cache memory의 값이 증가하는데..

우선, 잘 모르고 하는 질문이니 양해 바랍니다.

일반적으로 캐시 구조는 순차탐색을 이용하지 않나요?
순차탐색을 피하려면 캐시에 대한 테이블이 따로 정의되어 있어야 할 것 같은데..
그렇다면, 그냥 페이지 테이블을 사용하여 메모리를 참조하는 것과 별반 차이가 없을 듯 합니다.

가용 메모리의 대부분을 캐시로 사용할 때, 얻게 되는 이점이 무엇인지
궁금합니다.

캐시!하면 빠르다... 정도의 고정 관념을 가지는게 제 지식의 대부분인데... 이 경우는 flip-flop 등의 매체 자체의 특성이 아니었나 합니다.

메모리가 캐시로 사용되어 특별한 장점을 얻을려면 swap-out된 내용에 대한 이미지 등을 캐싱하고 있는 경우일 텐데... 이런 경우라면, 이미 페이지 테이블에서 유효(변경) 비트 등으로 참조하고 있지 않나요? 즉, 굳이 캐시라고 표현할 필요도 없이 페이지 테이블의 정의 자체에 유지하고 있는 정보가 아닌가 해서 질문 드립니다.

Linux 가 메모리상에 cache 영역을 남기는 것을 구분하자면
page cache 와 disk cache 로 나눌 수가 있죠.

page cache 는 빈번히 일어나는 메모리 할당/해제의 오버헤드를 줄이기 위해서
고안된 cache 이고,
disk cache 는 디스크를 읽는 횟수를 줄이기 위한 cache 입니다.
실제로 성능향상을 가져오는 것은 disk cache 라고 생각합니다.
(메모리나 CPU 에 비해서 그만큼 디스크가 느리기 때문이죠)

disk cache 는 VFS 레이어와 많은 상관관계를 가지고 있죠.
마운트한 파일시스템의 superblock 같은 메타데이터를 캐싱하는 것도
disk cache 에 포함되는 것이니 말이죠.

disk 상에서 특정 파일을 액세스 하는 경우,
해당 파일의 inode 에 붙는 디엔트리 객체에 disk cache 가 연결됩니다.
해당 파일을 더이상 사용하지 않더라도 읽어들인 내용을
그대로 메모리상에 유지하죠.
그 이후에 다시 해당 파일을 액세스 하는 경우에는 디스크 액세스를 하지 않고
메모리상에 남아있는 내용을 그대로 사용하죠.
이 경우의 성능향상은 압도적이죠.

수정) 틀린 내용이 있어 수정했습니다.
swap 영역이 줄어드는것을 "실제로" 보질 못해서 잘못 적었었네요.

그리고 위쪽 답변에서 간단히 쓰려고 안 적은 내용이 있는데...
cache 크기는 0이 될 수 없습니다.
항상 캐시하며, 메모리가 모자라는 경우에도 해제하지 않는 cache 가 존재하기 때문이죠.
대표적인 것이 Filesystem 의 superblock 같은 메타데이타들입니다.
이녀석들은 unmount 하기 전에는 캐시를 없애지 않습니다.

우선 여기서 주제가 되는 메모리 캐시와 실제 캐시 메모리와는
전혀 다른 객체가 아닌가 하는 것입니다. 왠지 캐시를 위한
추가적인 자료구조가 있는 것처럼 가정을 하고 답변을 하신듯 해서
(생각일 뿐입니다.)
즉,
위에서 말하는 page cache건 buffer cache건 실제로는
일단 필요에 의해서 메모리에 올라온 페이지일 뿐이라는 겁니다.
약간 과장하면 아무런 추가적인 자료구조나 관리가 필요없는 단지 메모리상의 페이지일뿐이 아닌가 하는 것입니다.

우리가 캐시로 잡혀 있는 것처럼 보고받는 캐시 사용량은 단지 변경 비트가 set되지 않아서 해당 페이지에 대한 참조시에는 추가적인 I/O가 발생할 필요없이 다시 재사용할 수 있어서... 이를 캐시라 보고하는 것으로 알고있었습니다.
( :D 부디 소스봤냐? 라고 묻지는 마시기를)
따라서 시스템이 정적인 활동을 오래할 수록 변경 비트가 set되지 않은 페이지들은 많아질 것이고 당연히 이를 캐시인 것처럼 합산하여 보고하는 것으로 알고 있었는데....

만약, 위의 제 생각이 틀리다면, 캐시를 관리하는 추가적인 테이블이
필요할 것이고 페이지 테이블 관리에 드는 오버헤드만큼이나 시스템에게는 버거운 작업이 될 것일텐데 하는 생각입니다.

정리하면, 시스템이 캐시로 보고하는 내용은 그저 현재 프로세스 집합이 재사용가능한 페이지 집합일 뿐이다. 이의 계산은 페이지 테이블내의 변경 비트가 셋팅되지 않는 페이지의 양을 합한 것이다.... 입니다. 아닌가요?
물론, 캐시로 파악하는데 사용하는 알고리즘이 시간, 보호 여부, 공유 여부, 참조 횟수 등으로 복잡하기는 하겠지만, 이는 시스템에서 따로 관리하는 객체는 아닌 것으로 알고 있었다는.....쩝.

게다가 실제로는 캐시와 swap-out과는 그리 큰 관련이 없어야 정상아닌가요?
즉, swap-out이 메모리가 부족한 경우에 자주 발생하기는 하지만,
근본적으로는 DOM(degree of multiprogramming) 수준을 낮추기 위한 것으로, DOM의 평가는 가용 메모리의 여부로만 판단하지는 않습니다. 즉, 메모리에 여유가 있을지라도 제출된 프로세스의 수가 과다하여 스케줄링에 우선순위를 적용할 수가 없다거나, 장시간 I/O를 위해 대기한다거나 하여도 swap-out은 언제든지 발생할 수 있는 걸로 알고 있었는데....

에궁... 길어졌습니다.
질문을 정리해보자면,
1. page cache건 buffer cache건 일반적으로는 그저 재사용가능한 페이지의 수를 합산한 것에 불과하다(buffer cache의 경우 fflush의 대상이라면 당연히 cache에 잡히지 않겠죠)
2. 메모리 부족 시 swap-out이 발생하긴 하지만, 그 이외의 경우에도 언제든지 swap-out이 발생할 수 있다. 왜냐하면, 시스템이 감당하기 어려운 DOM 수준은 메모리 부족 이외에도 여러가지 상황이 있을 수 있기 때문이다.

아참.... 그리고 오래전부터 궁금했었는데..
혹시 buffer-cache와 cache-buffer의 차이점에 대해 설명해 주시면.... 월매나 감솨할까요... 언젠가 책을 보는데 캐시 버퍼에 쓴다는 표현이 있어서... 꽤 찾았었는데.... 검색에 실패했다는...

맞습니다. 추가적인 오버헤드가 발생합니다. 때문에 굉장히 효율적으로 만들어지며, 아무리 오래걸린다 한들 disk i/o 한 번 줄이는 것이 훨씬 효과가 크기 때문에 사용되는 것입니다.

저도 찾아보긴 해야 하는데... 메모리 부족상황이 아니어도 swap-out 될 수 있다고 알고 있습니다. 실제로도 메모리가 많이 남는 상황에서 swap이 사용되는 것을 확인할 수 있구요.