linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hyeonggon Yoo <42.hyeyoo@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Vlastimil Babka <vbabka@suse.cz>, Baoquan He <bhe@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	akpm@linux-foundation.org, cl@linux.com,
	John.p.donnelly@oracle.com, kexec@lists.infradead.org,
	stable@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone
Date: Fri, 17 Dec 2021 11:38:52 +0000	[thread overview]
Message-ID: <Ybx2zGCvWGTmm2Ed@ip-172-31-30-232.ap-northeast-1.compute.internal> (raw)
In-Reply-To: <20211215072710.GA3010@lst.de>

On Wed, Dec 15, 2021 at 08:27:10AM +0100, Christoph Hellwig wrote:
> On Wed, Dec 15, 2021 at 07:03:35AM +0000, Hyeonggon Yoo wrote:
> > I'm not sure that allocating from ZONE_DMA32 instead of ZONE_DMA
> > for kdump kernel is nice way to solve this problem.
> 
> What is the problem with zones in kdump kernels?
> 
> > Devices that requires ZONE_DMA memory is rare but we still support them.
> 
> Indeed.
> 
> > >     1) Do not call warn_alloc in page allocator if will always fail
> > >     to allocate ZONE_DMA pages.
> > > 
> > > 
> > >     2) let's check all callers of kmalloc with GFP_DMA
> > >     if they really need GFP_DMA flag and replace those by DMA API or
> > >     just remove GFP_DMA from kmalloc()
> > > 
> > >     3) Drop support for allocating DMA memory from slab allocator
> > >     (as Christoph Hellwig said) and convert them to use DMA32
> > 
> > 	(as Christoph Hellwig said) and convert them to use *DMA API*
> > 
> > >     and see what happens
> 
> This is the right thing to do, but it will take a while.  In fact
> I dont think we really need the warning in step 1,

Hmm I think step 1) will be needed if someone is allocating pages from
DMA zone not using kmalloc or DMA API. (for example directly allocating
from buddy allocator) is there such cases?

> a simple grep
> already allows to go over them.  I just looked at the uses of GFP_DMA
> in drivers/scsi for example, and all but one look bogus.
>

That's good. this cleanup will also remove unnecessary limitations.

> > > > > Yeah, I have the same guess too for get_capabilities(), not sure about other
> > > > > callers. Or, as ChristophL and ChristophH said(Sorry, not sure if this is
> > > > > the right way to call people when the first name is the same. Correct me if
> > > > > it's wrong), any buffer requested from kmalloc can be used by device driver.
> > > > > Means device enforces getting memory inside addressing limit for those
> > > > > DMA transferring buffer which is usually large, Megabytes level with
> > > > > vmalloc() or alloc_pages(), but doesn't care about this kind of small
> > > > > piece buffer memory allocated with kmalloc()? Just a guess, please tell
> > > > > a counter example if anyone happens to know, it could be
> > > > > easy.
> 
> The way this works is that the dma_map* calls will bounce buffer memory
> that does to fall into the addressing limitations.  This is a performance
> overhead, but allows drivers to address all memory in a system.  If the
> driver controls memory allocation it should use one of the dma_alloc_*
> APIs that allocate addressable memory from the start.  The allocator
> will dip into ZONE_DMA and ZONE_DMA32 when needed.

  parent reply	other threads:[~2021-12-17 11:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 12:27 [PATCH v3 0/5] Avoid requesting page from DMA zone when no managed pages Baoquan He
2021-12-13 12:27 ` [PATCH v3 1/5] docs: kernel-parameters: Update to reflect the current default size of atomic pool Baoquan He
2021-12-13 14:20   ` john.p.donnelly
2021-12-13 12:27 ` [PATCH v3 2/5] dma-pool: allow user to disable " Baoquan He
2021-12-13 14:21   ` john.p.donnelly
2021-12-13 12:27 ` [PATCH v3 3/5] mm_zone: add function to check if managed dma zone exists Baoquan He
2021-12-13 14:22   ` john.p.donnelly
2021-12-16 10:52   ` David Hildenbrand
2021-12-13 12:27 ` [PATCH v3 4/5] dma/pool: create dma atomic pool only if dma zone has managed pages Baoquan He
2021-12-13 14:23   ` john.p.donnelly
2021-12-13 12:27 ` [PATCH v3 5/5] mm/slub: do not create dma-kmalloc if no managed pages in DMA zone Baoquan He
2021-12-13 13:43   ` Hyeonggon Yoo
2021-12-14  5:32     ` Baoquan He
2021-12-14 10:09       ` Vlastimil Babka
2021-12-14 10:28         ` Christoph Lameter
2021-12-15  4:48         ` Hyeonggon Yoo
2021-12-15  7:03           ` Hyeonggon Yoo
2021-12-15  7:27             ` Christoph Hellwig
2021-12-15 10:34               ` Vlastimil Babka
2021-12-15 11:51                 ` David Laight
2021-12-15 13:41                 ` Baoquan He
2021-12-17 11:38               ` Hyeonggon Yoo [this message]
2021-12-20  7:32                 ` Baoquan He
2022-01-07 11:56               ` Hyeonggon Yoo
2021-12-15 14:42             ` Baoquan He
2021-12-15 10:08         ` Baoquan He
2021-12-17 11:38       ` Hyeonggon Yoo
2021-12-21  8:56         ` Christoph Hellwig
2021-12-22 12:37           ` Hyeonggon Yoo
2021-12-23  8:52             ` Christoph Hellwig
2021-12-13 14:24   ` john.p.donnelly
2021-12-14 16:31   ` Christoph Hellwig
2021-12-14 17:07     ` john.p.donnelly
2021-12-15  7:27       ` Christoph Hellwig
2021-12-13 21:05 ` [PATCH v3 0/5] Avoid requesting page from DMA zone when no managed pages Andrew Morton
2021-12-14  0:35   ` Baoquan He

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=Ybx2zGCvWGTmm2Ed@ip-172-31-30-232.ap-northeast-1.compute.internal \
    --to=42.hyeyoo@gmail.com \
    --cc=John.p.donnelly@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=cl@linux.com \
    --cc=hch@lst.de \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=stable@vger.kernel.org \
    --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: 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;
as well as URLs for NNTP newsgroup(s).