Hi Yuenan,
On 5/22/26 21:56, zhaoyuenan wrote:
> Hi Chao,
>
> On 5/22/26 10:50, Chao Yu wrote:
>> Hi Yuenan,
>>
>> Thanks for your contribution!
>>
>> If there is a method to get pid via userspace, I prefer to do it in
>> userspace,
>> rather than implementing and maintaining an duplicated one in kernel.
>>
>> Or do you have a strong reason to do this in kernel?
>
> The main reason is that retrieving this PID from userspace is currently
> quite complex and fragile.
>
> Previously, userspace tools had to rely on pipelines like:
> pgrep f2fs_ckpt-$(ls -l /dev/block/by-name/userdata | awk '{print $5$6}' | tr
> ',' ':')
>
> This approach has a few drawbacks:
> 1. It requires parsing major/minor numbers and executing multiple commands,
> which is inefficient for simple monitoring tools.
I don't see why there is any performance concern in your scenario.
> 2. On some older kernels, the thread name can be truncated due to
> TASK_COMM_LEN
> limitations, causing 'pgrep' to fail to match the full 'f2fs_ckpt-X:Y'
> string.
I don't think this method has scalability, is it better to backport below
patch? so
that you can trace all kthreads and set them to target cgroup.
https://lore.kernel.org/all/[email protected]
Thanks,
>
> Exposing the PID via a sysfs node provides a deterministic, lightweight,
> and reliable way (just a simple 'cat') to fetch it without any userspace
> guessing or complex parsing.
>
> Does this address your concern?
>
> Thanks,
> Yuenan
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
