linux-kernel - Re: [v7 PATCH 1/2] mm: vmscan: remove double slab pressure by inc'ing sc->nr

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: <52ec93c6-a41b-e5aa-54f0-f508a5e30a09@linux.alibaba.com>
Date:   Tue, 11 Jun 2019 10:17:39 -0700
From:   Yang Shi <yang.shi@...ux.alibaba.com>
To:     Oscar Salvador <osalvador@...e.de>, ying.huang@...el.com,
        hannes@...xchg.org, mhocko@...e.com, mgorman@...hsingularity.net,
        kirill.shutemov@...ux.intel.com, josef@...icpanda.com,
        hughd@...gle.com, shakeelb@...gle.com, hdanton@...a.com,
        akpm@...ux-foundation.org
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [v7 PATCH 1/2] mm: vmscan: remove double slab pressure by inc'ing
 sc->nr_scanned



On 6/11/19 10:12 AM, Yang Shi wrote:
>
>
> On 6/10/19 2:36 PM, Oscar Salvador wrote:
>> On Tue, 2019-05-28 at 14:44 +0800, Yang Shi wrote:
>>> The commit 9092c71bb724 ("mm: use sc->priority for slab shrink
>>> targets")
>>> has broken up the relationship between sc->nr_scanned and slab
>>> pressure.
>>> The sc->nr_scanned can't double slab pressure anymore.  So, it sounds
>>> no
>>> sense to still keep sc->nr_scanned inc'ed.  Actually, it would
>>> prevent
>>> from adding pressure on slab shrink since excessive sc->nr_scanned
>>> would
>>> prevent from scan->priority raise.
>> Hi Yang,
>>
>> I might be misunderstanding this, but did you mean "prevent from scan-
>> priority decreasing"?
>> I guess we are talking about balance_pgdat(), and in case
>> kswapd_shrink_node() returns true (it means we have scanned more than
>> we had to reclaim), raise_priority becomes false, and this does not let
>> sc->priority to be decreased, which has the impact that less pages will
>>   be reclaimed the next round.
>
> Yes, exactly.

BTW, for the scan priority, the smaller number the higher priority. So, 
either "raise" or "decrease" sounds correct. "raise" means the real 
priority, "decrease" means the number itself.

>
>>
>> Sorry for bugging here, I just wanted to see if I got this right.
>>
>>
>