Static Trace Point에 관하여 Sep 1, 2009

http://lwn.net/Articles/245671/

좀 지나간 기사이지만, 갑자기 생각이 나서 읽어보았다.

Adding a test-and-jump operation to a kernel hot path will always be a hard sell; the cache effects of referencing a set of global marker state variables could also be significant.

http://thread.gmane.org/gmane.linux.kernel/568586

Immediate values are used as read mostly variables that are rarely updated. They
use code patching to modify the values inscribed in the instruction stream. It
provides a way to save precious cache lines that would otherwise have to be used
by these variables.

위의 2개의 link는 kernel marker가 구현될 당시,
관련 기사와 관련 패치의 일부이다.

인용구를 보면 알겠지만 mainline kernel developer들은
test-and-jump instruction 하나를 없애기 위해서도
저렇게 애를 쓴다. 왜냐하면 그 문제를 풀지 못하면 mainline에
merge되기 어려울 테니. 왜 merge되기 어려울까?

kernel marker는 kernel의 static trace point의 일부이다. 그 얘기는 커널이
release되더라도 enable 되어야 한다는 것이다. 이 논리에 대해서
이해가 가지 않는가?

static trace point란 것은 dynamic probing과는 성격이 틀리다.
static trace point는 이미 커널의 잘(?) 정의된
곳에 삽입되어 있어야 한다. 그래서 system administrator들이나
kenrel developer들은 기존에 잘 정의되어 있는 trace point를 기반으로
시스템의 성능을 분석하기 때문이다. 그러므로 사실 static trace point의
hot issue는 성능문제도 있지만 어떤 곳에 static trace point를
정의할 것이냐가 더 중요하다.

다시 본론으로 들어가서 test-and-jump instruction을 제거하기
위해서 왜 그렇게 애를 쓰는가? 기껏해야 instruction 하나 더
수행하는 것인데? 라고 묻는다면.

test-and-jump중 test를 위해 사용되는 shared variable은 귀중한
cache line을 한 line 소모한다. 그런데 shared varible은 하나일까?

1. static trace point 전체를 enable/disable할수 있으면 좋을까? 아님,
각각의 trace point를 enable/disable할 수 있으면 더 좋을까?
2. 그럼 그런 shared varibale가 하나가 필요할까? 두개가 필요할까?
3. 그럼 cache line을 하나만 소비할까? 두개 소비할까?
4. 그런데 이 trace point가 kernel의 hot path 중 하나에 들어간다면.
test를 위해서는 memory를 referencing해야 하고, 그럼 cache line이
하나가 소비될 것이고, 그 얘기는 worst case 기존에 cache line이
하나 eviction되야 하고, hot path라면 이게 반복될 것이고...

결국, trace point가 없을 때에 비해 working set의 많은 부분들이
cache line에서 eviction될 수 있다는 것이다.

왜 갑자기 뜬금없이 barrios가 잘알지도 못하는 kernel의 marker에
대해 이런 부분들을 언급하는가?

Engineer로써 생각해 볼 건 생각해보고 지킬 건 지키자.

꼬랑지) kernel marker와 tracepoint에 대해 많은 사람들이
그 쓰임새를 혼돈하고 있는 것 같다. 다음을 참조하자.
http://ltt.polymtl.ca/tracingwiki/index.php/Tracepoints_and_Markers

Markers are very much like Tracepoints, except that they declare a format string and export the data through a variable argument list. There is a small overhead associated with variable argument lists and the associated interpretation of the format string. The type of the arguments is also normally restricted to scalar types which can easily be described by the format string. The advantage of Markers is that they are self described. They do not require a prior declaration in an include (.h) file, and they can be processed by a generic probe, expecting a printf-like variable argument list.

Markers are thus used for simple ad-hoc instrumentation. Tracepoints are typically used when a formal hook is desired at an important location in the code. A tracepoint in the code is less visually invasive than a marker since it only contains the relevant arguments (no format string). Furthermore, a tracepoint is a general hooking mechanism which may be used for different purposes, one of which being tracing. The disadvantage is that for each tracepoint the developer must provide a prior definition and a corresponding probe.