From: Michal Hocko <mhocko@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Huaisheng Ye <yehs2007@gmail.com>,
akpm@linux-foundation.org, linux-mm@kvack.org, vbabka@suse.cz,
mgorman@techsingularity.net, kstewart@linuxfoundation.org,
alexander.levin@verizon.com, gregkh@linuxfoundation.org,
colyli@suse.de, chengnt@lenovo.com, hehy1@lenovo.com,
linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
xen-devel@lists.xenproject.org, linux-btrfs@vger.kernel.org,
Huaisheng Ye <yehs1@lenovo.com>
Subject: Re: [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD
Date: Thu, 24 May 2018 17:29:43 +0200 [thread overview]
Message-ID: <20180524152943.GA11881@dhcp22.suse.cz> (raw)
In-Reply-To: <20180524151818.GA21245@bombadil.infradead.org>
On Thu 24-05-18 08:18:18, Matthew Wilcox wrote:
> On Thu, May 24, 2018 at 02:23:23PM +0200, Michal Hocko wrote:
> > > If we had eight ZONEs, we could offer:
> >
> > No, please no more zones. What we have is quite a maint. burden on its
> > own. Ideally we should only have lowmem, highmem and special/device
> > zones for directly kernel accessible memory, the one that the kernel
> > cannot or must not use and completely special memory managed out of
> > the page allocator. All the remaining constrains should better be
> > implemented on top.
>
> I believe you when you say that they're a maintenance pain. Is that
> maintenance pain because they're so specialised?
Well, it used to be LRU balancing which is gone with the node reclaim
but that brings new challenges. Now as you say their meaning is not
really clear to users and that leads to bugs left and right.
> ie if we had more,
> could we solve our pain by making them more generic?
Well, if you have more you will consume more bits in the struct pages,
right?
[...]
> > But those already do have aproper API, IIUC. So do we really need to
> > make our GFP_*/Zone API more complicated than it already is?
>
> I don't want to change the driver API (setting the DMA mask, etc),
> but we don't actually have a good API to the page allocator for the
> implementation of dma_alloc_foo() to request pages. More or less,
> architectures do:
>
> if (mask < 4GB)
> alloc_page(GFP_DMA)
> else if (mask < 64EB)
> alloc_page(GFP_DMA32)
> else
> alloc_page(GFP_HIGHMEM)
>
> it more-or-less sucks that the devices with 28-bit DMA limits are forced
> to allocate from the low 16MB when they're perfectly capable of using the
> low 256MB.
Do we actually care all that much about those? If yes then we should
probably follow the ZONE_DMA (x86) path and use a CMA region for them.
I mean most devices should be good with very limited addressability or
below 4G, no?
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-05-24 15:29 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-21 15:20 Huaisheng Ye
2018-05-21 15:20 ` [RFC PATCH v2 01/12] include/linux/gfp.h: " Huaisheng Ye
2018-05-21 15:20 ` [RFC PATCH v2 02/12] arch/x86/kernel/amd_gart_64: update usage of address zone modifiers Huaisheng Ye
2018-05-22 9:38 ` Christoph Hellwig
2018-05-22 10:17 ` [External] " Huaisheng HS1 Ye
2018-05-21 15:20 ` [RFC PATCH v2 03/12] arch/x86/kernel/pci-calgary_64: " Huaisheng Ye
2018-05-21 15:20 ` [RFC PATCH v2 04/12] drivers/iommu/amd_iommu: " Huaisheng Ye
2018-05-21 15:20 ` [RFC PATCH v2 05/12] include/linux/dma-mapping: " Huaisheng Ye
2018-05-21 15:30 ` Christoph Hellwig
2018-05-21 15:20 ` [RFC PATCH v2 10/12] mm/zsmalloc: " Huaisheng Ye
2018-05-22 11:22 ` Matthew Wilcox
2018-05-22 11:51 ` [External] " Huaisheng HS1 Ye
2018-05-21 15:20 ` [RFC PATCH v2 11/12] include/linux/highmem: update usage of movableflags Huaisheng Ye
2018-05-21 15:20 ` [RFC PATCH v2 12/12] arch/x86/include/asm/page.h: " Huaisheng Ye
2018-05-22 9:40 ` [RFC PATCH v2 00/12] get rid of GFP_ZONE_TABLE/BAD Christoph Hellwig
2018-05-22 18:37 ` Michal Hocko
2018-05-23 16:07 ` [External] " Huaisheng HS1 Ye
2018-05-24 12:18 ` Michal Hocko
2018-05-25 9:43 ` Huaisheng HS1 Ye
2018-05-28 13:37 ` Michal Hocko
2018-05-30 9:02 ` Huaisheng HS1 Ye
2018-05-30 9:11 ` Christoph Hellwig
2018-05-30 9:12 ` Michal Hocko
2018-05-24 5:19 ` Matthew Wilcox
2018-05-24 12:23 ` Michal Hocko
2018-05-24 15:18 ` Matthew Wilcox
2018-05-24 15:29 ` Michal Hocko [this message]
2018-05-25 12:00 ` Matthew Wilcox
2018-05-28 13:33 ` Michal Hocko
2018-05-22 10:22 Huaisheng HS1 Ye
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=20180524152943.GA11881@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.levin@verizon.com \
--cc=chengnt@lenovo.com \
--cc=colyli@suse.de \
--cc=gregkh@linuxfoundation.org \
--cc=hehy1@lenovo.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=xen-devel@lists.xenproject.org \
--cc=yehs1@lenovo.com \
--cc=yehs2007@gmail.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox