linux-kernel - RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page arrival

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: <D6EDEBF1F91015459DB866AC4EE162CC023F8E78@IRSMSX103.ger.corp.intel.com>
Date:	Thu, 9 Jun 2016 08:01:52 +0000
From:	"Odzioba, Lukasz" <lukasz.odzioba@...el.com>
To:	Michal Hocko <mhocko@...nel.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"aarcange@...hat.com" <aarcange@...hat.com>,
	"vdavydov@...allels.com" <vdavydov@...allels.com>,
	"mingli199x@...com" <mingli199x@...com>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"Hansen, Dave" <dave.hansen@...el.com>,
	"Anaczkowski, Lukasz" <lukasz.anaczkowski@...el.com>
Subject: RE: [PATCH 1/1] mm/swap.c: flush lru_add pvecs on compound page
 arrival

On Wed 08-07-16 17:04:00, Michal Hocko wrote: 
> I do not see how a SIGTERM would make any difference. But see below.

This is how we encounter this problem initially, by hitting ctr-c while
running parallel  memory intensive workload, which ended up
not calling munmap on allocated memory.

> Is this really true? Both munmap and exit_mmap do the same
> lru_add_drain() which flushes only the local CPU cache so munmap
> shouldn't make any difference.

Damn, I forgot to escape # in pragma parallel, it should be
void main(){
#pragma parallel
{
(...)

And then yes, exit_mmap will flush just the local CPU cache, but not the
rest. This would be another way of fixing the problem, but I concluded
that it would hurt performance on short running processes like scripts
if we do it synchronously, and we will be racing with next processes if 
we do it asynchronously, not tested it though.

> I believe this deserves a more explanation. What do you think about the
> following.
> "
> The primary point of the LRU add cache is to save the zone lru_lock
> contention with a hope that more pages will belong to the same zone
> and so their addition can be batched. The huge page is already a
> form of batched addition (it will add 512 worth of memory in one go)
> so skipping the batching seems like a safer option when compared to a
> potential excess in the caching which can be quite large and much
> harder to fix because lru_add_drain_all is way to expensive and
> it is not really clear what would be a good moment to call it.
>"
>
> Does this sound better?

Far better, thanks.

Lukas