linux-kernel - Re: [PATCH V2 7/7] mm: add a separate RSS for MADV

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]

Message-ID: <20170222012712.GA97403@shli-mbp.local>
Date:   Tue, 21 Feb 2017 17:27:13 -0800
From:   Shaohua Li <shli@...com>
To:     Minchan Kim <minchan@...nel.org>
CC:     <linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
        <Kernel-team@...com>, <danielmicay@...il.com>, <mhocko@...e.com>,
        <hughd@...gle.com>, <hannes@...xchg.org>, <riel@...hat.com>,
        <mgorman@...hsingularity.net>, <akpm@...ux-foundation.org>
Subject: Re: [PATCH V2 7/7] mm: add a separate RSS for MADV_FREE pages

On Wed, Feb 22, 2017 at 09:46:05AM +0900, Minchan Kim wrote:
> Hi Shaohua,
> 
> On Fri, Feb 03, 2017 at 03:33:23PM -0800, Shaohua Li wrote:
> > Add a separate RSS for MADV_FREE pages. The pages are charged into
> > MM_ANONPAGES (because they are mapped anon pages) and also charged into
> > the MM_LAZYFREEPAGES. /proc/pid/statm will have an extra field to
> > display the RSS, which userspace can use to determine the RSS excluding
> > MADV_FREE pages.
> 
> I'm not sure statm is right place. With definition of statm and considering
> your usecase, it would be right place but when I look "stuats", it already
> shows RssAnon, RssFile and RssShmem so I thought we can add RssLazy to it.
> It would be more consistent if you don't have big overhead.
> 
> > 
> > The basic idea is to increment the RSS in madvise and decrement in unmap
> > or page reclaim. There is one limitation. If a page is shared by two
> > processes, since madvise only has mm cotext of current process, it isn't
> > convenient to charge the RSS for both processes. So we don't charge the
> > RSS if the mapcount isn't 1. On the other hand, fork can make a
> > MADV_FREE page shared by two processes. To make things consistent, we
> > uncharge the RSS from the source mm in fork.
> 
> I don't understand why we need new flag.
> 
> What's the problem like handling it normal anon|file|swapent|shmem?
> IOW, we can increase in madvise context and increase for child in copy_one_pte
> if the pte is still not dirty. And then decrease it in zap_pte_range/
> try_to_unmap_one if it finds it's dirty or discardable.
> 
> Although it's shared by fork, VM can discard it if processes doesn't
> make it dirty.

The thing is we could madvise the same page twice. madvise context can't
guarantee we move the page to inactive file list, so we could wrongly increase
the count.

> > 
> > A new flag is added to indicate if a page is accounted into the RSS. We
> > can't use SwapBacked flag to do the determination because we can't
> > guarantee the page has SwapBacked flag cleared in madvise. We are
> > reusing mappedtodisk flag which should not be set for Anon pages.
> > 
> > There are a couple of other places we need to uncharge the RSS,
> > activate_page and mark_page_accessed. activate_page is used by swap,
> > where MADV_FREE pages are already not in lazyfree state before going
> > into swap. mark_page_accessed is mainly used for file pages, but there
> > are several places it's used by anonymous pages. I fixed gup, but not
> > some gpu drivers and kvm. If the drivers use MADV_FREE, we might have
> > inprecise RSS accounting.
> > 
> > Please note, the accounting is never going to be precise. MADV_FREE page
> > could be written by userspace without notification to the kernel. The
> > page can't be reclaimed like other clean lazyfree pages. The page isn't
> > real lazyfree page. But since kernel isn't aware of this, the page is
> > still accounted as lazyfree, thus the accounting could be incorrect.
> 
> Right. Lazyfree is not inaccurate without CoW where it's point to decrease
> lazyfree rss count when the store happens so we might be tempted to make
> it to Cow at the cost of performance degradation but still it's not accurate
> without making mark_page_accessed be aware of each mm context which is
> hard part. So, I agree this stat is useful but don't want to make it
> complicate.

Yes, it only could be accurate with extra pagefault cost, but apparently nobody
wants to pay for it.

I talked to jemalloc guys here. They have concerns about the accounting since
it's not accurate. I'll drop the accounting patches in next post. The only
interface which can export accurate info is /proc/pid/smaps, we probably go
that.

Thanks,
Shaohua