Re: [PATCH V5] Tracepoint Tapset for Memory Subsystem

[Rajasekhar Duddu <rajduddu@linux.vnet.ibm.com>]

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.