From: Vlastimil Babka <vbabka@suse.cz> To: Michal Hocko <mhocko@kernel.org>, Joonsoo Kim <js1304@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Rik van Riel <riel@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, mgorman@techsingularity.net, Laura Abbott <lauraa@codeaurora.org>, Minchan Kim <minchan@kernel.org>, Marek Szyprowski <m.szyprowski@samsung.com>, Michal Nazarewicz <mina86@mina86.com>, "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>, Russell King <linux@armlinux.org.uk>, Will Deacon <will.deacon@arm.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@lge.com Subject: Re: [PATCH v7 0/7] Introduce ZONE_CMA Date: Tue, 2 May 2017 10:06:01 +0200 [thread overview] Message-ID: <32ac1107-14a3-fdff-ad48-0e246fec704f@suse.cz> (raw) In-Reply-To: <20170427150636.GM4706@dhcp22.suse.cz> On 04/27/2017 05:06 PM, Michal Hocko wrote: > On Tue 25-04-17 12:42:57, Joonsoo Kim wrote: >> On Mon, Apr 24, 2017 at 03:09:36PM +0200, Michal Hocko wrote: >>> On Mon 17-04-17 11:02:12, Joonsoo Kim wrote: >>>> On Thu, Apr 13, 2017 at 01:56:15PM +0200, Michal Hocko wrote: >>>>> On Wed 12-04-17 10:35:06, Joonsoo Kim wrote: > [...] >>> not for free. For most common configurations where we have ZONE_DMA, >>> ZONE_DMA32, ZONE_NORMAL and ZONE_MOVABLE all the 3 bits are already >>> consumed so a new zone will need a new one AFAICS. >> >> Yes, it requires one more bit for a new zone and it's handled by the patch. > > I am pretty sure that you are aware that consuming new page flag bits > is usually a no-go and something we try to avoid as much as possible > because we are in a great shortage there. So there really have to be a > _strong_ reason if we go that way. My current understanding that the > whole zone concept is more about a more convenient implementation rather > than a fundamental change which will solve unsolvable problems with the > current approach. More on that below. I don't see it as such a big issue. It's behind a CONFIG option (so we also don't need the jump labels you suggest later) and enabling it reduces the number of possible NUMA nodes (not page flags). So either you are building a kernel for android phone that needs CMA but will have a single NUMA node, or for a large server with many nodes that won't have CMA. As long as there won't be large servers that need CMA, we should be fine (yes, I know some HW vendors can be very creative, but then it's their problem?). > [...] >> MOVABLE allocation will fallback as following sequence. >> >> ZONE_CMA -> ZONE_MOVABLE -> ZONE_HIGHMEM -> ZONE_NORMAL -> ... Hmm, so this in effect resembles some of the aggressive CMA utilization efforts that were never merged due to issues. Joonsoo, could you summarize/expand the cover letter part on what were the issues with aggressive CMA utilization, and why they no longer apply with ZONE_CMA, especially given the current node-lru reclaim? Thanks.
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz> To: Michal Hocko <mhocko@kernel.org>, Joonsoo Kim <js1304@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org>, Rik van Riel <riel@redhat.com>, Johannes Weiner <hannes@cmpxchg.org>, mgorman@techsingularity.net, Laura Abbott <lauraa@codeaurora.org>, Minchan Kim <minchan@kernel.org>, Marek Szyprowski <m.szyprowski@samsung.com>, Michal Nazarewicz <mina86@mina86.com>, "Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>, Russell King <linux@armlinux.org.uk>, Will Deacon <will.deacon@arm.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@lge.com Subject: Re: [PATCH v7 0/7] Introduce ZONE_CMA Date: Tue, 2 May 2017 10:06:01 +0200 [thread overview] Message-ID: <32ac1107-14a3-fdff-ad48-0e246fec704f@suse.cz> (raw) In-Reply-To: <20170427150636.GM4706@dhcp22.suse.cz> On 04/27/2017 05:06 PM, Michal Hocko wrote: > On Tue 25-04-17 12:42:57, Joonsoo Kim wrote: >> On Mon, Apr 24, 2017 at 03:09:36PM +0200, Michal Hocko wrote: >>> On Mon 17-04-17 11:02:12, Joonsoo Kim wrote: >>>> On Thu, Apr 13, 2017 at 01:56:15PM +0200, Michal Hocko wrote: >>>>> On Wed 12-04-17 10:35:06, Joonsoo Kim wrote: > [...] >>> not for free. For most common configurations where we have ZONE_DMA, >>> ZONE_DMA32, ZONE_NORMAL and ZONE_MOVABLE all the 3 bits are already >>> consumed so a new zone will need a new one AFAICS. >> >> Yes, it requires one more bit for a new zone and it's handled by the patch. > > I am pretty sure that you are aware that consuming new page flag bits > is usually a no-go and something we try to avoid as much as possible > because we are in a great shortage there. So there really have to be a > _strong_ reason if we go that way. My current understanding that the > whole zone concept is more about a more convenient implementation rather > than a fundamental change which will solve unsolvable problems with the > current approach. More on that below. I don't see it as such a big issue. It's behind a CONFIG option (so we also don't need the jump labels you suggest later) and enabling it reduces the number of possible NUMA nodes (not page flags). So either you are building a kernel for android phone that needs CMA but will have a single NUMA node, or for a large server with many nodes that won't have CMA. As long as there won't be large servers that need CMA, we should be fine (yes, I know some HW vendors can be very creative, but then it's their problem?). > [...] >> MOVABLE allocation will fallback as following sequence. >> >> ZONE_CMA -> ZONE_MOVABLE -> ZONE_HIGHMEM -> ZONE_NORMAL -> ... Hmm, so this in effect resembles some of the aggressive CMA utilization efforts that were never merged due to issues. Joonsoo, could you summarize/expand the cover letter part on what were the issues with aggressive CMA utilization, and why they no longer apply with ZONE_CMA, especially given the current node-lru reclaim? Thanks. -- 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:[~2017-05-02 8:06 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-11 3:17 [PATCH v7 0/7] Introduce ZONE_CMA js1304 2017-04-11 3:17 ` js1304 2017-04-11 3:17 ` [PATCH v7 1/7] mm/page_alloc: don't reserve ZONE_HIGHMEM for ZONE_MOVABLE request js1304 2017-04-11 3:17 ` js1304 2017-04-17 7:38 ` Minchan Kim 2017-04-17 7:38 ` Minchan Kim 2017-04-21 1:32 ` Joonsoo Kim 2017-04-21 1:32 ` Joonsoo Kim 2017-04-11 3:17 ` [PATCH v7 2/7] mm/cma: introduce new zone, ZONE_CMA js1304 2017-04-11 3:17 ` js1304 2017-04-11 3:17 ` [PATCH v7 3/7] mm/cma: populate ZONE_CMA js1304 2017-04-11 3:17 ` js1304 2017-04-11 3:17 ` [PATCH v7 4/7] mm/cma: remove ALLOC_CMA js1304 2017-04-11 3:17 ` js1304 2017-04-11 3:17 ` [PATCH v7 5/7] mm/cma: remove MIGRATE_CMA js1304 2017-04-11 3:17 ` js1304 2017-04-11 3:17 ` [PATCH v7 6/7] mm/cma: remove per zone CMA stat js1304 2017-04-11 3:17 ` js1304 2017-04-11 3:17 ` [PATCH v7 7/7] ARM: CMA: avoid re-mapping CMA region if CONFIG_HIGHMEM js1304 2017-04-11 3:17 ` js1304 2017-04-11 18:15 ` [PATCH v7 0/7] Introduce ZONE_CMA Michal Hocko 2017-04-11 18:15 ` Michal Hocko 2017-04-12 1:35 ` Joonsoo Kim 2017-04-12 1:35 ` Joonsoo Kim 2017-04-13 11:56 ` Michal Hocko 2017-04-13 11:56 ` Michal Hocko 2017-04-17 2:02 ` Joonsoo Kim 2017-04-17 2:02 ` Joonsoo Kim 2017-04-21 1:35 ` Joonsoo Kim 2017-04-21 1:35 ` Joonsoo Kim 2017-04-21 6:54 ` Michal Hocko 2017-04-21 6:54 ` Michal Hocko 2017-04-24 13:09 ` Michal Hocko 2017-04-24 13:09 ` Michal Hocko 2017-04-25 3:42 ` Joonsoo Kim 2017-04-25 3:42 ` Joonsoo Kim 2017-04-27 15:06 ` Michal Hocko 2017-04-27 15:06 ` Michal Hocko 2017-04-28 8:04 ` Generic approach to customizable zones - was: " Igor Stoppa 2017-04-28 8:04 ` Igor Stoppa 2017-04-28 8:36 ` Michal Hocko 2017-04-28 8:36 ` Michal Hocko 2017-04-28 9:04 ` Igor Stoppa 2017-04-28 9:04 ` Igor Stoppa 2017-05-02 4:01 ` Joonsoo Kim 2017-05-02 4:01 ` Joonsoo Kim 2017-05-02 13:32 ` Michal Hocko 2017-05-02 13:32 ` Michal Hocko 2017-05-11 2:12 ` Joonsoo Kim 2017-05-11 2:12 ` Joonsoo Kim 2017-05-11 9:13 ` Michal Hocko 2017-05-11 9:13 ` Michal Hocko 2017-05-12 2:00 ` Joonsoo Kim 2017-05-12 2:00 ` Joonsoo Kim 2017-05-12 6:38 ` Michal Hocko 2017-05-12 6:38 ` Michal Hocko 2017-05-15 3:57 ` Joonsoo Kim 2017-05-15 3:57 ` Joonsoo Kim 2017-05-16 8:47 ` Michal Hocko 2017-05-16 8:47 ` Michal Hocko 2017-05-17 7:44 ` Joonsoo Kim 2017-05-17 7:44 ` Joonsoo Kim 2017-05-02 8:06 ` Vlastimil Babka [this message] 2017-05-02 8:06 ` Vlastimil Babka 2017-05-02 13:03 ` Michal Hocko 2017-05-02 13:03 ` Michal Hocko 2017-05-02 13:41 ` Igor Stoppa 2017-05-02 13:41 ` Igor Stoppa 2017-05-04 12:33 ` Vlastimil Babka 2017-05-04 12:33 ` Vlastimil Babka 2017-05-04 12:46 ` Michal Hocko 2017-05-04 12:46 ` Michal Hocko 2017-05-11 8:51 ` Vlastimil Babka 2017-05-11 8:51 ` Vlastimil Babka 2017-04-12 1:39 ` Joonsoo Kim 2017-04-12 1:39 ` Joonsoo Kim 2017-04-24 4:08 ` Bob Liu 2017-04-24 4:08 ` Bob Liu
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=32ac1107-14a3-fdff-ad48-0e246fec704f@suse.cz \ --to=vbabka@suse.cz \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.vnet.ibm.com \ --cc=hannes@cmpxchg.org \ --cc=js1304@gmail.com \ --cc=kernel-team@lge.com \ --cc=lauraa@codeaurora.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux@armlinux.org.uk \ --cc=m.szyprowski@samsung.com \ --cc=mgorman@techsingularity.net \ --cc=mhocko@kernel.org \ --cc=mina86@mina86.com \ --cc=minchan@kernel.org \ --cc=riel@redhat.com \ --cc=will.deacon@arm.com \ /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.