This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH V5] Tracepoint Tapset for Memory Subsystem
On Mon, Dec 07, 2009 at 10:49:59AM +0800, Wenji Huang wrote:
> Hi,
>
> Rajasekhar Duddu wrote:
>> +/* The Formal Parameters will be displayed if available, otherwise \
>> + "0" or "unknown" will be displayed */
>> +
>> +probe __vm.kmalloc.tp = kernel.trace("kmalloc") {
>> + name = "kmalloc"
>> + call_site = $call_site
>> + caller_function = symname(call_site)
>> + bytes_req = $bytes_req
>> + bytes_alloc = $bytes_alloc
>> + gfp_flags = $gfp_flags
>> + gfp_flag_name = __gfp_flag_str($gfp_flags)
>> + ptr = $ptr
>> +}
>> +
>> +/* It is unsafe to invoke __builtin_return_address() \
>> +presently(to get call_site for kporbe based probes) \
>> +and that it can be improved later when fix for bugs bz#6961 and bz#6580 is available. */
>> +
>> +probe __vm.kmalloc.kp = kernel.function("kmalloc").return {
>> + name = "kmalloc"
>> + call_site = 0
>> + caller_function = "unknown"
>> + bytes_req = $size
>> + bytes_alloc = "unknown"
> why let bytes_alloc be "unknown", not 0 ?
> The type is not consistent with the above one.
>
> Same issue exists in the following part.
>
Hi Wenji,
I do agree with you that type is not consistent here, but if
bytes_alloc is assigined "0" , it may indicate a failure.
When Memory allacation is successful then bytes_alloc would be
non-zero which we are not able to fetch here, so I feel its not
good to assign it with zero.
Thanks
--
Rajasekhar Duddu (rajduddu@linux.vnet.ibm.com),
Linux on System z - CSVT, IBM LTC, Bangalore.