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:   Mon, 6 Feb 2017 16:12:03 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     vinayak menon <vinayakm.list@...il.com>
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 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...

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