From: Minchan Kim <minchan@kernel.org> To: Michal Hocko <mhocko@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@techsingularity.net>, Vlastimil Babka <vbabka@suse.cz>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sangseok Lee <sangseok.lee@lge.com> Subject: Re: [PATCH 0/4] use up highorder free pages before OOM Date: Tue, 11 Oct 2016 14:06:43 +0900 [thread overview] Message-ID: <20161011050643.GC30973@bbox> (raw) In-Reply-To: <20161010074724.GC20420@dhcp22.suse.cz> 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@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Minchan Kim <minchan@kernel.org> To: Michal Hocko <mhocko@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org>, Mel Gorman <mgorman@techsingularity.net>, Vlastimil Babka <vbabka@suse.cz>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sangseok Lee <sangseok.lee@lge.com> Subject: Re: [PATCH 0/4] use up highorder free pages before OOM Date: Tue, 11 Oct 2016 14:06:43 +0900 [thread overview] Message-ID: <20161011050643.GC30973@bbox> (raw) In-Reply-To: <20161010074724.GC20420@dhcp22.suse.cz> 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@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-10-11 5:06 UTC|newest] Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-10-07 5:45 [PATCH 0/4] use up highorder free pages before OOM Minchan Kim 2016-10-07 5:45 ` Minchan Kim 2016-10-07 5:45 ` [PATCH 1/4] mm: adjust reserved highatomic count Minchan Kim 2016-10-07 5:45 ` Minchan Kim 2016-10-07 12:30 ` Vlastimil Babka 2016-10-07 12:30 ` Vlastimil Babka 2016-10-07 14:29 ` Minchan Kim 2016-10-07 14:29 ` Minchan Kim 2016-10-10 6:57 ` Vlastimil Babka 2016-10-10 6:57 ` Vlastimil Babka 2016-10-11 4:19 ` Minchan Kim 2016-10-11 4:19 ` Minchan Kim 2016-10-11 9:40 ` Vlastimil Babka 2016-10-11 9:40 ` Vlastimil Babka 2016-10-12 5:36 ` Mel Gorman 2016-10-12 5:36 ` Mel Gorman 2016-10-07 5:45 ` [PATCH 2/4] mm: prevent double decrease of nr_reserved_highatomic Minchan Kim 2016-10-07 5:45 ` Minchan Kim 2016-10-07 12:44 ` Vlastimil Babka 2016-10-07 12:44 ` Vlastimil Babka 2016-10-07 14:30 ` Minchan Kim 2016-10-07 14:30 ` Minchan Kim 2016-10-12 5:36 ` Mel Gorman 2016-10-12 5:36 ` Mel Gorman 2016-10-07 5:45 ` [PATCH 3/4] mm: unreserve highatomic free pages fully before OOM Minchan Kim 2016-10-07 5:45 ` Minchan Kim 2016-10-07 9:09 ` Michal Hocko 2016-10-07 9:09 ` Michal Hocko 2016-10-07 14:43 ` Minchan Kim 2016-10-07 14:43 ` Minchan Kim 2016-10-10 7:41 ` Michal Hocko 2016-10-10 7:41 ` Michal Hocko 2016-10-11 5:01 ` Minchan Kim 2016-10-11 5:01 ` Minchan Kim 2016-10-11 6:50 ` Michal Hocko 2016-10-11 6:50 ` Michal Hocko 2016-10-11 7:09 ` Minchan Kim 2016-10-11 7:09 ` Minchan Kim 2016-10-11 7:26 ` Michal Hocko 2016-10-11 7:26 ` Michal Hocko 2016-10-11 7:37 ` Minchan Kim 2016-10-11 7:37 ` Minchan Kim 2016-10-11 8:01 ` Michal Hocko 2016-10-11 8:01 ` Michal Hocko 2016-10-07 5:45 ` [PATCH 4/4] mm: skip to reserve pageblock crossed zone boundary for HIGHATOMIC Minchan Kim 2016-10-07 5:45 ` Minchan Kim 2016-10-07 9:16 ` [PATCH 0/4] use up highorder free pages before OOM Michal Hocko 2016-10-07 9:16 ` Michal Hocko 2016-10-07 15:04 ` Minchan Kim 2016-10-07 15:04 ` Minchan Kim 2016-10-10 7:47 ` Michal Hocko 2016-10-10 7:47 ` Michal Hocko 2016-10-11 5:06 ` Minchan Kim [this message] 2016-10-11 5:06 ` Minchan Kim 2016-10-11 6:53 ` Michal Hocko 2016-10-11 6:53 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20161011050643.GC30973@bbox \ --to=minchan@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=iamjoonsoo.kim@lge.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mhocko@kernel.org \ --cc=sangseok.lee@lge.com \ --cc=vbabka@suse.cz \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.