buffered-io가 사용하는 버퍼메모리에 대한 질문있어요

Question

먼저 항상 특별한 강의 잘 듣고있습니다. 감사합니다.

1. buffered-io의 buffer 메모리는 어플리케이션 메모리죠?
제가 이해하기로는
buffered-io방식으로 write를 한다면 호출시 바로바로 write시스템콜을 호출하는게아니라, 버퍼라고 부르는 어플리케이션메모리에 내용을 써놨다가 일정 byte이상 차게되면 실제 write시스템콜을 호출함으로써 시스템콜을 줄일 수 있는게 핵심이라고 이해했는데 맞을까요?
결국에 이때 buffer라는 memory는 어플리케이션의 메모리를 말하는거죠? (커널의 메모리가 아니구요)

2. read(input)에서의 buffered-io
시스템콜을 한방에 하기위해서 최대한 뒤로 미루는 버퍼방식의 write와 비교해서
read의 경우에는 일단 시스템콜을 호출해야할것같은데 맞나요? 따라서 read에서의 buffered-io는 모아서 시스템콜을 한다기보다는 buffer라는 chunk단위로 한방에 읽을 수 있는걸 buffered-io한다고 이해하면 맞을까요?
제가 이해하기로는 buffered-io에서의 buffering방식이 read시에, write시에 다르게 느껴져서요.

널널한 개발자 · Answer

시스템 콜 수준이 아니라 시스템 콜과 응용 프로그램 중간에 있는 운영체제 수준 서비스에 존재하는것으로 이해할 수 있겠습니다. 그리고 생각하신바가 맞습니다. 잦은 시스템 콜은 잦은 커널모드 스위칭을 유발하며 비효율의 원인이 될 수 있습니다. 아울러 커널에서도 입/출력은 위한 버퍼는 있을 수 있습니다. 성능 극대화를 위해 응용 프로그램 수준 Buffer 메모리를 커널이 Lock하고 사용하는 구조도 있습니다. 대표적으로 윈도우의 IOCP가 그런 구조입니다. 꼭 그렇지는 않습니다. 파일의 일종인 소켓의 경우 흐름제어를 위해 Read 대기가 생깁니다. 경우에 따라 손실된 정보를 재수신해야 할 수 있기 때문입니다. 물론 로컬 HDD에 대한 Read 실패는 고려의 대상이 아닐 수 있기 때문에 둘을 같은 것으로 생각할 수는 없겠으나 비교해볼 필요는 있습니다. 결과적으로 Buffered I/O의 Buffer는 관리 기법이 다를 뿐 Read/Write 모두에 적용될 수 있습니다. 그러한 커널의 관리가 불필요하다면 명시적으로 Non-buffered I/O를 요청하면 되는 것이고요. 참고하시기 바랍니다. 감사합니다.