linux-kernel - Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Feb 2017 16:47:18 +0530
From:   vinayak menon <vinayakm.list@...il.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Vinayak Menon <vinmenon@...eaurora.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>,
        mgorman@...hsingularity.net, vbabka@...e.cz,
        Rik van Riel <riel@...hat.com>, vdavydov.dev@...il.com,
        anton.vorontsov@...aro.org, Minchan Kim <minchan@...nel.org>,
        shashim@...eaurora.org, "linux-mm@...ck.org" <linux-mm@...ck.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2 RESEND] mm: vmpressure: fix sending wrong events on underflow

On Mon, Feb 6, 2017 at 8:42 PM, Michal Hocko <mhocko@...nel.org> wrote:
> On Mon 06-02-17 20:05:21, vinayak menon wrote:
> [...]
>> By scan I meant pages scanned by shrink_node_memcg/shrink_list
>> which is passed as nr_scanned to vmpressure.  The calculation of
>> pressure for tree is done at the end of vmpressure_win and it is
>> that calculation which underflows. With this patch we want only the
>> underflow to be avoided. But if we make (reclaimed = scanned) in
>> vmpressure(), we change the vmpressure value even when there is no
>> underflow right ?
>>
>> Rewriting the above e.g again.  First call to vmpressure with
>> nr_scanned=1 and nr_reclaimed=512 (THP) Second call to vmpressure
>> with nr_scanned=511 and nr_reclaimed=0 In the second call
>> vmpr->tree_scanned becomes equal to vmpressure_win and the work
>> is scheduled and it will calculate the vmpressure as 0 because
>> tree_reclaimed = 512
>>
>> Similarly, if scanned is made equal to reclaimed in vmpressure()
>> itself as you had suggested, First call to vmpressure with
>> nr_scanned=1 and nr_reclaimed=512 (THP) And in vmpressure, we
>> make nr_scanned=1 and nr_reclaimed=1 Second call to vmpressure
>> with nr_scanned=511 and nr_reclaimed=0 In the second call
>> vmpr->tree_scanned becomes equal to vmpressure_win and the work is
>> scheduled and it will calculate the vmpressure as critical, because
>> tree_reclaimed = 1
>>
>> So it makes a difference, no?
>
> OK, I see what you meant. Thanks for the clarification. And you are
> right that normalizing nr_reclaimed to nr_scanned is a wrong thing to
> do because that just doesn't aggregate the real work done. Normalizing
> nr_scanned to nr_reclaimed should be better - or it would be even better
> to count the scanned pages properly...
>
With the slab reclaimed issue fixed separately, only the THP case exists AFAIK.
In the case of THP, as I understand from one of Minchan's reply, the scan is
actually 1. i.e. Only a single huge page is scanned to get 512 reclaimed pages.
So the cost involved was scanning a single page.
In that case, there is no need to normalize the nr_scanned, no?

> My main concern of doing this normalization late on aggregated numbers
> is just weird. We are mixing numbers from parallel reclaimers and that
> might just add more confusion. It is better to do the fixup as soon as
> possible when we still have at least an idea that this was a THP page
> scanned and reclaimed.
>
> If we get back to your example it works as you expect just due to good
> luck. Just make your nr_scanned=511 and nr_reclaimed=0 be a separate
> event and you have your critical event. You have no real control over
> when a new event is fired because parallel reclaimers are basically
> unpredictable.
> --
> Michal Hocko
> SUSE Labs