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

[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@xxxxxxxxxx>
> >>
> >> 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?

-- 
Michal Hocko
SUSE Labs