Re: [PATCH] proc: Move OOM-related procfs code to fs/proc/oom.c

[Ye Liu <ye.liu@linux.dev>]

在 2026/10/15 18:54, Michal Hocko 写道:
> On Thu 15-10-26 09:32:53, Ye Liu wrote:
>>
>>
>> 在 2026/10/14 17:32, Michal Hocko 写道:
>>> On Wed 14-10-26 16:54:12, Ye Liu wrote:
>>>> From: Ye Liu <liuye@kylinos.cn>
>>>>
>>>> fs/proc/base.c is a large file (~3700 lines) handling all per-process
>>>> procfs entries. The OOM score, oom_adj, and oom_score_adj interface
>>>> code is self-contained and has no dependencies on other parts of
>>>> base.c, so move it into a dedicated fs/proc/oom.c following the same
>>>> pattern as fs/proc/fd.c and fs/proc/task_mmu.c.
>>>>
>>>> This makes both files easier to read and keeps OOM-related procfs
>>>> entries together in one place.
>>>
>>> Are there plans to separate other functionality or is this one off
>>> thing?
>>> In general I am not against of moving stuff to more specialized files.
>>> An obvious downside is a review as it is quite easy to overlook a subtle
>>> change when moving so much code. Something worth undertaking if there
>>> is a bigger goal. Not so sure if this is just a one of and fs/proc/base.c
>>> still keeps other random stuff in.
>>>
>>
>> Hi Michal,
>>
>> This is a one-off move specifically for the OOM-related procfs code.
>> I don't have a broader plan to split up fs/proc/base.c at this time.
>>
>> I understand the concern about subtle changes during code moves.
>> To address that, the patch is a pure relocation with no functional
>> modifications — all function bodies are moved verbatim. 
> 
> But you do understand that I effectivelly need to redo the patch to
> confirm this is the case, right?
> 
> This is something I am not particularly thrilled to do for a single
> isolated patch without a larger plan. taks_mmu.c will remain a huge pile
> of code after this change. So what's the point for all that effort?
> 
My familiarity with fs/proc/base.c is currently limited to the OOM-related
code. Meaningfully splitting other parts of base.c would require time to
study those modules first, which I don't have available in the near term.
I may revisit a broader cleanup when I have the bandwidth to do it properly.

For now, I'd like to withdraw this patch rather than leave it hanging.

Appreciate the review.

-- 
Thanks,
Ye Liu