linux-kernel - Re: [PATCH 0/4] use up highorder free pages before OOM

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161011050643.GC30973@bbox>
Date:   Tue, 11 Oct 2016 14:06:43 +0900
From:   Minchan Kim <minchan@...nel.org>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Vlastimil Babka <vbabka@...e.cz>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Sangseok Lee <sangseok.lee@....com>
Subject: Re: [PATCH 0/4] use up highorder free pages before OOM

On Mon, Oct 10, 2016 at 09:47:31AM +0200, Michal Hocko wrote:
> On Sat 08-10-16 00:04:25, Minchan Kim wrote:
> [...]
> > I can show other log which reserve greater than 1%. See the DMA32 zone
> > free pages. It was GFP_ATOMIC allocation so it's different with I posted
> > but important thing is VM can reserve memory greater than 1% by the race
> > which was really what we want.
> > 
> > in:imklog: page allocation failure: order:0, mode:0x2280020(GFP_ATOMIC|__GFP_NOTRACK)
> [...]
> > DMA: 7*4kB (UE) 3*8kB (UH) 1*16kB (M) 0*32kB 2*64kB (U) 1*128kB (M) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 1*4096kB (H) = 7748kB
> > DMA32: 10*4kB (H) 3*8kB (H) 47*16kB (H) 38*32kB (H) 5*64kB (H) 1*128kB (H) 2*256kB (H) 3*512kB (H) 3*1024kB (H) 3*2048kB (H) 4*4096kB (H) = 30128kB
> 
> Yes, this sounds like a bug. Please add this information to the patch
> which aims to fix the misaccounting.

No problem.

> 
> > > So while I do agree that potential issues - misaccounting and others you
> > > are addressing in the follow up patch - are good to fix but I believe that
> > > draining last 19M is not something that would reliably get you over the
> > > edge. Your workload (93% of memory sitting on anon LRU with swap full)
> > > simply doesn't fit into the amount of memory you have available.
> > 
> > What happens if the workload fit into additional 19M memory?
> > I admit my testing aimed for proving the problem but with this patchset,
> > there is no OOM killing with many free pages and the number of OOM was
> > reduced highly. It is definitely better than old.
> > 
> > Please don't ignore 1% memory in embedded system. 20M memory in 2G system,
> > If we can use those for zram, it is 60~80M memory via compression.
> > You should know how many engineers try to reduce 1M of their driver to
> > cost down of the product, seriously.
> 
> I am definitely not ignoring neither embedded systems nor 1% of the
> memory that might really matter. I just wanted to point out that being

Whew and I thought you were serious.

> that close to OOM usually blows up later or starts trashing very soon.
> It is true that a particular workload might benefit from ever last
> allocatable page in the system but it would be better to mention all
> that in the changelog.

I don't unerstand what phrase you really want to include the changelog.
I will add the information which isolate 30M free pages before 4K page
allocation failure in next version. If you want something to add,
please say again.

Thanks for the review, Michal.

> -- 
> Michal Hocko
> SUSE Labs
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@...ck.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>