This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
container_of - complex indirections - guru code - workqueues
- From: "Turgis, Frederic" <f-turgis at ti dot com>
- To: SystemTap <systemtap at sourceware dot org>
- Date: Thu, 29 Sep 2011 01:17:00 +0200
- Subject: container_of - complex indirections - guru code - workqueues
Hi,
I have assumed that guru code is only method to get data in following cases:
1 - data is retrieved by a "container_of(...)" syntax
2 - specific method like
unsigned long data = atomic_long_read(&work->data);
return (void *)(data & WORK_STRUCT_WQ_DATA_MASK); => then it would do (struct cpu_workqueue_struct *)data->wq->name
Is it right ?
On top of that, I also have the issue that definitions are sometimes internal to C file like "struct cpu_workqueue_struct" so I mix guru code and @cast (summarized below):
function get_workqueue_pointer:long(ref:long) %{
struct work_struct *work; unsigned long data;
work = (struct work_struct *)((uint32_t)(THIS->ref));
data = atomic_long_read(&work->data);
THIS->__retvalue = (data & WORK_STRUCT_WQ_DATA_MASK);
%}
probe kernel.function("process_one_work") {
workqueue = get_workqueue_pointer($work);
printf("process_one_work %p %s \n", $work->func, kernel_string(@cast(workqueue, "struct cpu_workqueue_struct")->wq->name));
}
Sounds reasonable or too hackish (shall I duplicate kernel code into my script) ? If you look at the code, you may find better solutions using same probe at a specific line of code but I wanted something more maintainable
For curious people, I am doing this because of June patch on workqueues: it gathered associated kernel threads into a common pool so there is no direct association between kernel thread and workqueue name. You only get "kworker/x:y" or "kworker/u:y" task name :-( Worse, 1 execution of a kworker task can correspond to consecutive executions of several workqueues. So I needed to track "process_one_work(...)" execution with pointer on function executed and related workqueue name.
A final good probing approach could be interesting to be added to "scheduler" examples. I am "happy" with mine but experts can probably improve.
Regards
Fred
Frederic Turgis
OMAP Platform Business Unit - OMAP System Engineering - Platform Enablement
Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920