> > I agree that we need to be frugal with the addition of trace points. But

> > I don't think the bugs that can be solved with this is always reproducible

> > by the developer.

> >

> > If you have a distribution kernel that is running at a customers location,

> > you may not have the privilege of shutting down that kernel, patching the

> > code, recompiling and booting up this temporary kernel. It would be nice

> > to have strategic locations in the kernel where we can easily enable a

> > trace point and monitor what is going on.

> >

> > If the customer calls and tells you there's some strange performance

> > issues when running such and such a load, it would be nice to look at

> > things like workqueues to analyze the situation.

>

> Would it?  What's the probability that anyone anywhere will *really*

> solve an on-site problem using workqueue tracepoints?  Just one person?

>

> I think the probability is quite small, and I doubt if it's high enough

> to add permanent code to the kernel.

>

> Plus: what we _really_ should be looking at is

>

> p(someone uses this for something) -

>       p(they could have used a kprobes-based tracer)



This is starting to sound a lot like catch 22. We don't want it in the

kernel if nobody is using it. But nobody is using it because it is not in

the kernel.

Andrew Morton： そんなにトレースポイントって必要か？ kprobe based tracerでいいじゃん
Steven Rostedt： キャッチ２２的な状況だね。誰も使わないトレースポイントは入れたくないが
カーネルにマージしないかぎりは誰も使わないに決まってる。

Wikipediaのキャッチ２２の項
を見ると要するにパラドクスとかジレンマとかそういうニュアンスらしい。

http://blog.goo.ne.jp/batchmongara/e/746b113e763278d9a017b3b417432448

「だいじょうぶ、問題ない、ほら簡単、楽勝だろう」 という意味らしい

例文：

>

>> -__ending_string(name, src)

ftrace で __ending_string() という新しいタイプを追加したくてだな。やっぱり固定長配列しかないのは不便なのだよ。トレースデータは先頭にサイズが入っているんだから、最後のメンバだけは可変長にしてもサイズは逆算できるはずで・・・
とかいう議論をしている。

> > can't we simply do __string(name, src) and output something like:
> >
> > struct {
> > u16 size;
> > char str[0];
> > } name;
> >
> > That would get rid of this __ending_ wart.

__ending なしの __string() にできないの？ こんな風に


> Hmm, I don't understand.
> Such a thing doesn't seem to work. Once we fill the string it would
> override the fields that
> follow it if it's not at the end.

うむむ、よく分からん。
それは動かんように見えるぞ。その構造体をラストメンバ以外で使ったら後続メンバをオーバライドしちゃうじゃん

Just grow the thing to fit whatever string length -- rather common
pattern:

struct foo {
int length;
char data[0];
};

struct foo *bar = kmalloc(sizeof(struct foo) + data_size);

いやいや、kmallocのサイズを変えるだけじゃん

and bob's your uncle.

楽勝だろ？

とかとか。
このあと、トレースでkmallocは使えねーんだよﾊﾞｰﾔﾊﾞｰﾔ。とか議論があった後以下の仕様になった。

__field(int, foo);
__string(bar);
__field(int, foo2);
__string(bar2);
__field(int, foo3);

こんな感じで適当にメンバを宣言していく


struct plop {
int foo;
char *bar;
int foo2;
char *bar2;
int foo3;

char data[0];
}

これが、こんな構造体に変換される。でbarとかba2はdata配列のどこかのインデックスをポイントしている。

で、呼び出し方はこう

size = sizeof(struct plop);
size += strlen(bar) + 1;
size += strlen(bar2) + 1;

event = ring_buffer_lock_reserve(size);
offset = sizeof(struct plop);
my_plop.bar = (char *)offset;
offset += strlen(bar) + 1;
my_plop.bar2 = (char *)offset;
memcpy(&event, &my_plop, sizeof(struct plop));
memcpy(&event + my_plop.bar, bar, strlen(bar)+1);
memcpy(&event + my_plop.bar2, bar2, strlen(bar2)+1);
ring_buffer_unlock();

http://eow.alc.co.jp/last+resort/UTF-8/

・ last resort
最後｛さいご｝の手段｛しゅだん｝、苦肉｛くにく｝の策、伝家の宝刀、頼みの綱、最終審｛さいしゅうしん｝
・I've got to go with the last resort. : こうなったら最後の手段しかない

よく使うよね　＞　最後の手段

最初に見た時は、「前回行ったリゾート？話そらすなボケ！今はカーネルの話をしとるんじゃ！！」とか思ったものだが :-p

> > Could you please update Documentation/ftrace.txt?
> > I guess many user interesting this patch. :)
>
> Yeah, it has become a really nice feature this way. As i told it
> to K.Prasad before: we need this tracer because the data tracer
> will likely become the most common usecase of this facility. We
> will get the hw breakpoints facility tested and used.
>
> And in fact we can go one step further: it would also be nice to
> wire it up with the ftrace histogram code: so that we can get
> usage histograms of kernel symbol read/write activities without
> the overhead of tracing. (The branch tracer already has this.)
>
> Especially frequently used variables generate a _lot_ of events.
>
> Ingo

Right, it will even be an occasion to improve and further test
the histogram tracing.
K. Prasad if you need some help on how to use it, don't hesitate to tell.

Frederic.

please don't hesitate to tell. で遠慮せずに聞いてね。という慣用句らしい

追記：
id:kazuhookuさんから、「don't hesitate to ask の間違いでなくて? 」とツッコミをいただいた。
たぶん正当英語的にはaskなんだと思う。LKMLはウソ英語の巣窟なので、細かいことは気にしてはいけないんだという、いいサンプルになってしまった。

Tom Zanussi pointed out that the simple TRACE_FIELD was not enough to
record trace data that required memcpy. This patch addresses this issue
by adding a TRACE_FIELD_SPECIAL. The format is similar to TRACE_FIELD
but looks like so:

「パッチ address プロブレム名」 で、このパッチはこのプロブレムに（取り組む｜対処する）パッチだよん。
という風に書く。

オレ、なんか見逃してるかい？

ってこと。レビューで相手に反論をひとしきり書いたあとにつける、常套句。

D&Dの世界では「つおい」マジックアイテムぐらいの意味だが、LKMLだと「作為的」の意味で使われる。
ちょっと（ベンチマークの作りが）作為的じゃない？とかそういう用途

D&Dのアーティファクトといえば・・（脱線なので以下略）

> OK, so without text_poke, how does it deal with kernel with text pages
> marked read-only after boot ?

Actually, we cheat. If DYNAMIC_FTRACE is configured in, we do not set the
text sections to read only. But if this needs to be fixed, we can easily
change it so that before we do the convesion, we set all text back to
write and after the conversion we set it back to read. The conversion
itself is done via stop_machine, so we do not need to worry about other
things going on.

-- Steve

とりあえず、英語でもチートって言ってもいいということは分かった。

しかし、この仕様だとDYNAMIC_FTRACEは本番環境ではつかえんのぅ