LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-mm@kvack.org, mhocko@kernel.org, cl@linux.com,
	Jan Kara <jack@suse.cz>,
	matthew@wil.cx, x86@kernel.org, luto@amacapital.net,
	martin.petersen@oracle.com, jthumshirn@suse.de,
	broonie@kernel.org, Juergen Gross <jgross@suse.com>,
	linux-spi@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
	linux-scsi@vger.kernel.org,
	Dan Carpenter <dan.carpenter@oracle.com>,
	linux-kernel@vger.kernel.org,
	"lsf-pc@lists.linux-foundation.org"
	<lsf-pc@lists.linux-foundation.org>
Subject: Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love
Date: Sat, 28 Apr 2018 01:42:21 -0700	[thread overview]
Message-ID: <20180428084221.GD31684@infradead.org> (raw)
In-Reply-To: <20180427161456.GD27853@wotan.suse.de>

On Fri, Apr 27, 2018 at 04:14:56PM +0000, Luis R. Rodriguez wrote:
> But curious, on a standard qemu x86_x64 KVM guest, which of the
> drivers do we know for certain *are* being used from the ones
> listed?

On a KVM guest probably none.  But not all the world is relatively
sane and standardized VMs unfortunately.

> > But even more importantly
> > we have plenty driver using it through dma_alloc_* and a small DMA
> > mask, and they are in use 
> 
> Do we have a list of users for x86 with a small DMA mask?
> Or, given that I'm not aware of a tool to be able to look
> for this in an easy way, would it be good to find out which
> x86 drivers do have a small mask?

Basically you'll have to grep for calls to dma_set_mask/
dma_set_coherent_mask/dma_set_mask_and_coherent and their pci_*
wrappers with masks smaller 32-bit.  Some use numeric values,
some use DMA_BIT_MASK and various places uses local variables
or struct members to parse them, so finding them will be a bit
more work.  Nothing a coccinell expert couldn't solve, though :)

> > - we actually had a 4.16 regression due to them.
> 
> Ah what commit was the culprit? Is that fixed already? If so what
> commit?

66bdb147 ("swiotlb: Use dma_direct_supported() for swiotlb_ops")

> > > SCSI is *severely* affected:
> > 
> > Not really.  We have unchecked_isa_dma to support about 4 drivers,
> 
> Ah very neat:
> 
>   * CONFIG_CHR_DEV_OSST - "SCSI OnStream SC-x0 tape support"
>   * CONFIG_SCSI_ADVANSYS - "AdvanSys SCSI support"
>   * CONFIG_SCSI_AHA1542 - "Adaptec AHA1542 support"
>   * CONFIG_SCSI_ESAS2R - "ATTO Technology's ExpressSAS RAID adapter driver"
> 
> > and less than a hand ful of drivers doing stupid things, which can
> > be fixed easily, and just need a volunteer.
> 
> Care to list what needs to be done? Can an eager beaver student do it?

Drop the drivers, as in my branch I prepared a while ago would be
easiest:

http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/unchecked_isa_dma

But unlike the other few aha1542 actually seems to have active users,
or at least had recently.  I'll need to send this out as a RFC, but
don't really expect it to fly.

If it doesn't we'll need to enhance swiotlb to support a ISA DMA pool
in addition to current 32-bit DMA pool, and also convert aha1542 to
use the DMA API.  Not really student material.

> > > That's the end of the review of all current explicit callers on x86.
> > > 
> > > # dma_alloc_coherent_gfp_flags() and dma_generic_alloc_coherent()
> > > 
> > > dma_alloc_coherent_gfp_flags() and dma_generic_alloc_coherent() set
> > > GFP_DMA if if (dma_mask <= DMA_BIT_MASK(24))
> > 
> > All that code is long gone and replaced with dma-direct.  Which still
> > uses GFP_DMA based on the dma mask, though - see above.
> 
> And that's mostly IOMMU code, on the alloc() dma_map_ops.

It is the dma mapping API, which translates the dma mask to the right
zone, and probably is the biggest user of ZONE_DMA in modern systems.

Currently there are still various arch and iommu specific
implementations of the allocator decisions, but I'm working to
consolidate them into common code.

  parent reply	other threads:[~2018-04-28  8:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 21:54 Luis R. Rodriguez
2018-04-27  1:09 ` [Lsf-pc] " Rik van Riel
2018-04-27  5:35 ` Christoph Hellwig
2018-04-27  7:18   ` Michal Hocko
2018-04-27 16:07     ` Christopher Lameter
2018-04-27 16:18       ` Matthew Wilcox
2018-04-27 16:36         ` Christopher Lameter
2018-04-28  8:33           ` Christoph Hellwig
2018-04-27 16:37       ` Michal Hocko
2018-04-28  8:33       ` Christoph Hellwig
2018-04-28  8:30     ` Christoph Hellwig
2018-04-27 16:14   ` Luis R. Rodriguez
2018-04-27 16:28     ` Matthew Wilcox
2018-04-28  8:42     ` Christoph Hellwig [this message]
2018-04-28 18:55       ` Luis R. Rodriguez
2018-04-28 19:46         ` Julia Lawall
2018-04-28 20:41           ` Matthew Wilcox
2018-04-29 14:34             ` Julia Lawall
     [not found]         ` <CAFhKne8u7KcBkpgiQ0fFZyh5_EorfY-_MJJaEYk3feCOd9LsRQ@mail.gmail.com>
2018-05-03 12:03           ` Michal Hocko
2018-05-03 12:13             ` Christoph Hellwig
2018-05-03  8:20 ` Geert Uytterhoeven
2018-05-05 16:08 ` Are media drivers abusing of GFP_DMA? - was: " Mauro Carvalho Chehab
2018-05-07 13:26   ` Laurent Pinchart
2018-05-07 15:19     ` Mauro Carvalho Chehab
2018-05-14  8:00       ` Fabien DESSENNE
2018-05-14 10:35         ` Mauro Carvalho Chehab
2018-05-14 10:39           ` Mauro Carvalho Chehab
2018-05-15  7:30             ` Fabien DESSENNE
2018-05-15  8:27               ` Laurent Pinchart
2018-05-15 10:30                 ` Mauro Carvalho Chehab
2018-05-15 16:24           ` Luis R. Rodriguez
2018-05-10  4:39   ` Yasunari.Takiguchi

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=20180428084221.GD31684@infradead.org \
    --to=hch@infradead.org \
    --cc=broonie@kernel.org \
    --cc=cl@linux.com \
    --cc=dan.carpenter@oracle.com \
    --cc=jack@suse.cz \
    --cc=jgross@suse.com \
    --cc=joro@8bytes.org \
    --cc=jthumshirn@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=luto@amacapital.net \
    --cc=martin.petersen@oracle.com \
    --cc=matthew@wil.cx \
    --cc=mcgrof@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=x86@kernel.org \
    --subject='Re: [LSF/MM TOPIC NOTES] x86 ZONE_DMA love' \
    /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

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).