정확히 "데이터 동기화"라는 용어를 어떤 의미에서 사용했는지 잘 모르겠습니다.

collect_stat_start이 실행시작될 때 순간의 percpu의 데이터를 정확히 읽어오는 것을 의미하시는건가요? 

네 그렇습니다.

해당 함수 진입 후 local_irq_disable 이전에 irq 요청이 들어와 핸들링하게 되면 어떤 플로우로 처리되는지 예상이 잘 안되는 것 같습니다.

전문가는 아니지만 제 의견을 드리자면..

local_irq_disable하기 전에 irq가 들어온다면,

collect_pcpu_stat_cb()

...   ---------interupt------>     percpu write

local_irq_disable()

percpu read

percpu write

local_irq_disable()

위와 같이 percpu 데이터가 갱신될 것 같네요. 그런 다음 갱신된 값을 global 카운터에 더합니다.

만약 local counter를 global counter로 합치는 일이 목적이라면 몇 가지 의문사항이 있습니다.

1) 굳이 local counter를 다시 0으로 세팅해야하는가?

만약 local counter에 write하지 않는다면, local_irq_disable()은 필요없어 보입니다.

2) for_each_possible_cpu(i)에서 smp_call_on_cpu를 사용하는 특별한 이유가 있는가?

해당 함수에서 per_cpu_ptr(ptr, cpu)으로 각 cpu의 local counter에 접근해도 문제없긴 합니다.

답변 감사합니다!

질문 주신 내용으로 보아 코드를 보신듯하여 자잘한 내용은 빼겠습니다.

2) 현재 코드가 per-cpu에서 읽은 뒤 해당 변수를 0으로 초기화하도록 되어 있는데 smp_call_on_cpu를 사용하지 않으면 동기화 이슈가 생길 것이라 판단하였습니다. 예를 들어 for_each_possible_cpu를 실행하는 context는 cpu4인데 cpu0의 per-cpu 데이터를 읽고 "쓰기(0으로 reset 하는 코드)"를 수행해야 하기 때문입니다. 그래서 cpu마다 workq를 할당하도록 해당 함수를 이용하였습니다.

답변 해주신 내용을 읽고 곰곰히 생각해보니 패킷 통계값은 계속 per-cpu 변수에 저장해놓고 user가 proc 파일을 read할 때 per_cpu_ptr로 접근해 읽은 뒤 sum 하여 리턴하는 것이 더 효율적이라 생각되어 해당 방법으로 수정할 예정입니다 ㅎ 이와 별개로 추가 기능을 넣을 계획이 있는데 그 기능은 아마 저 방식을 써야하지 않을까 싶습니다.

>답변 해주신 내용을 읽고 곰곰히 생각해보니 패킷 통계값은 계속 per-cpu 변수에 저장해놓고 user가 proc 파일을 read할 때 per_cpu_ptr로 접근해 읽은 뒤 sum 하여 리턴하는 것이 더 효율적이라 생각되어 해당 방법으로 수정할 예정입니다

이제 해당 방식의 문제는, 빈번하게 read가 발생할 때, 성능저하가 발생할 수 있는데 precision과 trade off할 수 있습니다.

리눅스에서 Counter를 사용하는 방식을 살펴보는 것도 도움이 될 것 같습니다. 

http://jake.dothome.co.kr/zonned-allocator-watermark

위 링크의 "존 카운터(stat)" 키워드는 vm에서의 통계 값 처리하는 방식을 설명하고 있습니다.

또는 perfbook 책을 살펴보는 것도 도움이 됩니다.

perfbook 내용 너무 좋네요. 제가 궁금해 하던 것들 실마리가 대부분 들어 있는거 같습니다. 링크와 책 추천 고맙습니다!