linux-kernel - Re: [PATCH 2/2] mm: oom: dump single excessive slab cache when oom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <43776378-91f8-45f3-c5af-b1db00d0c6ce@alibaba-inc.com>
Date:   Wed, 01 Nov 2017 00:47:56 +0800
From:   "Yang Shi" <yang.s@...baba-inc.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] mm: oom: dump single excessive slab cache when oom



On 10/26/17 10:14 AM, Michal Hocko wrote:
> On Thu 26-10-17 18:27:01, Michal Hocko wrote:
>> On Fri 27-10-17 00:15:17, Yang Shi wrote:
>>>
>>>
>>> On 10/26/17 7:53 AM, Michal Hocko wrote:
>>>> On Thu 26-10-17 06:49:00, Yang Shi wrote:
>>>>> Per the discussion with David [1], it looks more reasonable to just dump
>>>>
>>>> Please try to avoid external references in the changelog as much as
>>>> possible.
>>>
>>> OK.
>>>
>>>>
>>>>> the single excessive slab cache instead of dumping all slab caches when
>>>>> oom.
>>>>
>>>> You meant to say
>>>> "to just dump all slab caches which excess 10% of the total memory."
>>>>
>>>> While we are at it. Abusing calc_mem_size seems to be rather clumsy and
>>>> tt is not nodemask aware so you the whole thing is dubious for NUMA
>>>> constrained OOMs.
>>>
>>> Since we just need the total memory size of the node for NUMA constrained
>>> OOM, we should be able to use show_mem_node_skip() to bring in nodemask.
>>
>> yes
> 
> to be more specific. This would work for the total number of pages
> calculation. This is still not enough, though. You would also have to
> filter slabs per numa node and this is getting more and more complicated
> for a marginal improvement.

Yes, it sounds so. Basically, I agree with you to wait for a while to 
see how the current implementation is doing.

Thanks,
Yang

>