Messages in this thread | | | Date | Thu, 9 Jun 2022 11:19:23 -0400 | Subject | Re: [PATCH 03/13] mm: shmem: provide oom badness for shmem files | From | Felix Kuehling <> |
| |
Am 2022-06-09 um 10:21 schrieb Michal Hocko: > On Thu 09-06-22 16:10:33, Christian König wrote: >> Am 09.06.22 um 14:57 schrieb Michal Hocko: >>> On Thu 09-06-22 14:16:56, Christian König wrote: >>>> Am 09.06.22 um 11:18 schrieb Michal Hocko: >>>>> On Tue 31-05-22 11:59:57, Christian König wrote: >>>>>> This gives the OOM killer an additional hint which processes are >>>>>> referencing shmem files with potentially no other accounting for them. >>>>>> >>>>>> Signed-off-by: Christian König <christian.koenig@amd.com> >>>>>> --- >>>>>> mm/shmem.c | 6 ++++++ >>>>>> 1 file changed, 6 insertions(+) >>>>>> >>>>>> diff --git a/mm/shmem.c b/mm/shmem.c >>>>>> index 4b2fea33158e..a4ad92a16968 100644 >>>>>> --- a/mm/shmem.c >>>>>> +++ b/mm/shmem.c >>>>>> @@ -2179,6 +2179,11 @@ unsigned long shmem_get_unmapped_area(struct file *file, >>>>>> return inflated_addr; >>>>>> } >>>>>> +static long shmem_oom_badness(struct file *file) >>>>>> +{ >>>>>> + return i_size_read(file_inode(file)) >> PAGE_SHIFT; >>>>>> +} >>>>> This doesn't really represent the in memory size of the file, does it? >>>> Well the file could be partially or fully swapped out as anonymous memory or >>>> the address space only sparse populated, but even then just using the file >>>> size as OOM badness sounded like the most straightforward approach to me. >>> It covers hole as well, right? >> Yes, exactly. > So let's say I have a huge sparse shmem file. I will get killed because > the oom_badness of such a file would be large as well...
Would killing processes free shmem files, though? Aren't those persistent anyway? In that case, shmem files should not contribute to oom_badness at all.
I guess a special case would be files that were removed from the filesystem but are still open in some processes.
Regards, Felix
> >>>> What could happen is that the file is also mmaped and we double account. >>>> >>>>> Also the memcg oom handling could be considerably skewed if the file was >>>>> shared between more memcgs. >>>> Yes, and that's one of the reasons why I didn't touched the memcg by this >>>> and only affected the classic OOM killer. >>> oom_badness is for all oom handlers, including memcg. Maybe I have >>> misread an earlier patch but I do not see anything specific to global >>> oom handling. >> As far as I can see the oom_badness() function is only used in >> oom_kill.c and in procfs to return the oom score. Did I missed >> something? > oom_kill.c implements most of the oom killer functionality. Memcg oom > killing is a part of that. Have a look at select_bad_process. >
| |