Re: [PATCH v2 1/3] 99base: add memtrace-ko.sh to debug kernel module large memory consumption

[Xunlei Pang <xpang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On 2016/11/09 at 11:06, Pratyush Anand wrote:
>
>
> On Wednesday 09 November 2016 08:18 AM, Xunlei Pang wrote:
>>> > Moreover, do we really need to trace module_put? You have filter for module loading applications, and pids for different module load instances would be different, so even if module_put is not tracked, it should work, no?
>> We need to keep it, lets take an example to illustrate, "insmod mymodule" will hit "module_load" then "module_put"
>> (even for insert failed cases),  then other possible alloc_pages events, init function of the module is called between
>> "module_load" and the following "module_put" trace point, we only care about alloc_pages events captured in between.
>
> I do not have any strong feeling, so I am oK with what is there currently implemented in this patch.
>
> It was just to make it a bit more simple.
> - We will have trace event generated only for the module insertion process.
> - There would be a different PID for each insertion

This may not be true, AFAIK "systemd-udevd" can load multiple modules in the same task(same pid).
So we need to know when the process will finish for each loading.

Regards,
Xunlei

> - "The other possible alloc_pages events" described above would still belong to same insmod operation (from userspace). And we will not have any new page allocation until a new insmod or siblings start  (so a new PID). Therefore, why to set/unset.Just track with PID.
> -- 
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html