This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]