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 13:09:54 +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 Tue 07-02-17 16:47:18, vinayak menon wrote:
> 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?

Strictly speaking it is not but it has weird side effects when we
basically lie about vmpressure_win.

-- 
Michal Hocko
SUSE Labs