dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thellstrom@vmware.com>
To: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Felix.Kuehling@amd.com" <Felix.Kuehling@amd.com>,
	"Christian.Koenig@amd.com" <Christian.Koenig@amd.com>,
	"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
	"thomas@shipmail.org" <thomas@shipmail.org>
Subject: Re: [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems
Date: Fri, 22 Feb 2019 13:45:12 +0000	[thread overview]
Message-ID: <0c5e5ad70e2acbf2efd9fd0878768dcd5e008cd3.camel@vmware.com> (raw)
In-Reply-To: <0b52e5ed-aeac-16df-41a1-b64c050df485@amd.com>

On Fri, 2019-02-22 at 07:10 +0000, Koenig, Christian wrote:
> Am 21.02.19 um 22:02 schrieb Thomas Hellstrom:
> > Hi,
> > 
> > On Thu, 2019-02-21 at 20:24 +0000, Kuehling, Felix wrote:
> > > On 2019-02-21 12:34 p.m., Thomas Hellstrom wrote:
> > > > On Thu, 2019-02-21 at 16:57 +0000, Kuehling, Felix wrote:
> > > > > On 2019-02-21 2:59 a.m., Koenig, Christian wrote:
> > > > > > On x86 with HIGHMEM there is no dma32 zone. Why do we need
> > > > > > one
> > > > > > on
> > > > > > > > x86_64? Can we make x86_64 more like HIGHMEM instead?
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > >        Felix
> > > > > > > > 
> > > > > > > IIRC with x86, the kernel zone is always smaller than any
> > > > > > > dma32
> > > > > > > zone,
> > > > > > > so we'd always exhaust the kernel zone before dma32
> > > > > > > anyway.
> > > > > > > 
> > > > > > > Not sure why we have dma32 on x86 without highmem,
> > > > > > > though.
> > > > > > > sounds
> > > > > > > superflous but harmless.
> > > > > > Well DMA32 denotes memory which is accessible by devices
> > > > > > who
> > > > > > can
> > > > > > only do
> > > > > > 32bit addressing. And IIRC we can actually do DMA32 to
> > > > > > highmem
> > > > > > since
> > > > > > something like 2.4.*.
> > > > > > 
> > > > > > Because of this it is actually irrelevant if you have
> > > > > > highmem
> > > > > > or
> > > > > > not,
> > > > > > what matters for DMA32 is if you have an IOMMU or not.
> > > > > Are you saying we should have a dma32_zone even on x86 with
> > > > > HIGHMEM?
> > > > > 
> > > > > 
> > > > > > So even on x86_64 you actually do need the DMA32 zone if
> > > > > > you
> > > > > > don't
> > > > > > have
> > > > > > an IOMMU which remaps all memory for devices which can't
> > > > > > directly
> > > > > > address it.
> > > > > Why is DMA32 special in this way? For example AMD GFX8 GPUs
> > > > > support
> > > > > 40-bit DMA. But we don't have a special zone for that.
> > > > If you're running on a non-IOMMU system with physical memory
> > > > addresses
> > > > > 40 bits, and tell the DMA subsystem that you need to restrict
> > > > > to
> > > > > 40
> > > > bits, it will probably start using bounce buffers for streaming
> > > > DMA
> > > > (which won't work with most graphics drivers), or for
> > > > dma_alloc_coherent(), it will probably use memory from the
> > > > DMA32
> > > > zone.
> > > OK, then why is it not needed when CONFIG_HIGHMEM is defined?
> > > 
> > > I found that there is a CONFIG_ZONE_DMA32 parameter. Maybe we
> > > should
> > > use
> > > that to decide whether to account for the DMA32 zone in TTM. It
> > > is
> > > set
> > > on x86_64 and a number of other 64-bit architectures.
> > > 
> > > 
> > > > > How common is it to have devices that need DMA32 on an x86_64
> > > > > system?
> > > > IIRC All devices using dma_alloc_coherent() allocate DMA32
> > > > memory
> > > > unless they explicitly set the dma coherent mask to something
> > > > larger.
> > > > Like Christian says, if an IOMMU is present and enabled, the
> > > > need
> > > > for
> > > > the DMA32 zone goes away. In theory at least.
> > > Thanks. I read up a bit on DMA32 and memory zones in general. I
> > > found
> > > that there is a lowmem_reserve_ratio feature that protects
> > > against
> > > normal page allocations overflowing into lowmem zones. There is
> > > some
> > > documentation in Documentation/scsctl/vm.txt (search for
> > > lowmem_reserve_ratio). The protected amount of memory in each
> > > zone
> > > can
> > > be seen in /proc/zoneinfo.
> > > 
> > > With that, can we conclude that we don't need to count
> > > ttm_mem_global_alloc against the dma32 zone.
> > Yes, it indeed looks like that.
> > But then I would suggest removing the DMA32 zone entirely.
> 
> We still need it for the pages we allocate, but we should just stop 
> accounting all the housekeeping to it.

Why is that? Can't we just account all pages in the kernel zone, and
leave it up to the kernel to make sure there are still DMA32 pages
left?

/Thomas

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-02-22 13:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15 23:02 [PATCH 1/1] [RFC] drm/ttm: Don't init dma32_zone on 64-bit systems Kuehling, Felix
2019-02-18  8:02 ` Thomas Hellstrom
2019-02-18  9:20   ` Koenig, Christian
2019-02-18  9:47     ` Thomas Hellstrom
     [not found]       ` <d90f7ab569b636db0968c80dad9eb16ce7bf1eab.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-02-18 17:07         ` Christian König
     [not found]           ` <89c4b66a-152a-d0f3-4ce0-d89f6ef822bb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-02-18 20:39             ` Thomas Hellstrom
     [not found]               ` <eaad8f2dc24e98c68036801ccd6a871586033d31.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-02-19 17:06                 ` Kuehling, Felix
     [not found]                   ` <2be5739a-fe9a-f436-48a2-fb420cb97a13-5C7GfCeVMHo@public.gmane.org>
2019-02-20  6:41                     ` Thomas Hellstrom
     [not found]                       ` <19a0abdbd60c251a63975a7ddff31c35a5eb0a31.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-02-20  8:07                         ` Christian König
2019-02-20  8:14                           ` Thomas Hellstrom
     [not found]                             ` <307f2073-7c15-8dac-58fe-3c0170231530-4+hqylr40dJg9hUCZPvPmw@public.gmane.org>
2019-02-20  8:35                               ` Koenig, Christian
     [not found]                                 ` <66b1fa8a-6449-6fe2-18a0-c7aa2200ac68-5C7GfCeVMHo@public.gmane.org>
2019-02-20  9:01                                   ` Thomas Hellstrom
2019-02-20 19:23                         ` Kuehling, Felix
2019-02-21  6:47                           ` Thomas Hellstrom
2019-02-21  7:59                             ` Koenig, Christian
     [not found]                               ` <4423e7aa-2153-5305-91c2-8d212ae1786b-5C7GfCeVMHo@public.gmane.org>
2019-02-21 16:57                                 ` Kuehling, Felix
     [not found]                                   ` <2a76cb48-10f1-6df2-5b40-8d5b4c52acc4-5C7GfCeVMHo@public.gmane.org>
2019-02-21 17:34                                     ` Thomas Hellstrom
     [not found]                                       ` <39a4a5534ea3d5fa9ba94714e80f919c5a43aea9.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-02-21 20:24                                         ` Kuehling, Felix
     [not found]                                           ` <2b4ea7ed-08e6-6dd3-7b56-e7c1713fc357-5C7GfCeVMHo@public.gmane.org>
2019-02-21 21:02                                             ` Thomas Hellstrom
     [not found]                                               ` <0f1a3b818a4f6b426dff5c641332a456b08136f8.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-02-22  7:10                                                 ` Koenig, Christian
2019-02-22 13:45                                                   ` Thomas Hellstrom [this message]
     [not found]                                                     ` <0c5e5ad70e2acbf2efd9fd0878768dcd5e008cd3.camel-pghWNbHTmq7QT0dZR+AlfA@public.gmane.org>
2019-02-22 23:06                                                       ` Kuehling, Felix

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=0c5e5ad70e2acbf2efd9fd0878768dcd5e008cd3.camel@vmware.com \
    --to=thellstrom@vmware.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=thomas@shipmail.org \
    /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