dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Huang Rui <ray.huang@amd.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>
Cc: "Chauhan, Madhav" <Madhav.Chauhan@amd.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: drm/ttm: new TT backend allocation pool
Date: Mon, 26 Oct 2020 21:45:12 +0800	[thread overview]
Message-ID: <20201026134512.GA410214@hr-amd> (raw)
In-Reply-To: <20201025154100.16400-1-christian.koenig@amd.com>

On Sun, Oct 25, 2020 at 11:40:47PM +0800, Christian König wrote:
> This replaces the spaghetti code in the two existing page pools.
>     
> First of all depending on the allocation size it is between 3 (1GiB) and
> 5 (1MiB) times faster than the old implementation.
>     
> It makes better use of buddy pages to allow for larger physical contiguous
> allocations which should result in better TLB utilization at least for amdgpu.
>     
> Instead of a completely braindead approach of filling the pool with one CPU
> while another one is trying to shrink it we only give back freed pages.
>     
> This also results in much less locking contention and a trylock free MM
> shrinker callback, so we can guarantee that pages are given back to the system
> when needed.
>     
> Downside of this is that it takes longer for many small allocations until the
> pool is filled up. We could address this, but I couldn't find an use case
> where this actually matters. And we don't bother freeing large chunks of pages
> any more.
>     
> The sysfs files are replaced with a single module parameter, allowing users to
> override how many pages should be globally pooled in TTM. This unfortunately
> breaks the UAPI slightly, but as far as we know nobody ever depended on this.
>    
> Zeroing memory coming from the pool was handled inconsistently. The
> alloc_pages() based pool was zeroing it, the dma_alloc_attr() based one wasn't.
> The new implementation isn't zeroing pages from the pool either and only sets
> the __GFP_ZERO flag when necessary.
>     
> The implementation has only 753 lines of code compared to the over 2600 of the
> old one, and also allows for saving quite a bunch of code in the drivers since
> we don't need specialized handling there any more based on kernel config.
>   
> Additional to all of that there was a neat bug with IOMMU, coherent DMA
> mappings and huge pages which is now fixed in the new code as well.

Let me give a test your patch set in my renoir and new vangogh platform
with iommu enabled. (I actually encountered many page faults in legacy
ttm_page_alloc_dma implementation with swiotlb=1)

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

      parent reply	other threads:[~2020-10-26 13:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-25 15:40 drm/ttm: new TT backend allocation pool Christian König
2020-10-25 15:40 ` [PATCH 01/13] drm/ttm: nuke ttm_tt_set_(un)populated again Christian König
2020-10-26  4:43   ` Dave Airlie
2020-10-26 13:36   ` Chauhan, Madhav
2020-10-26 13:43     ` Christian König
2020-10-26 19:26       ` Chauhan, Madhav
2020-10-28 11:40         ` Chauhan, Madhav
2020-10-25 15:40 ` [PATCH 02/13] drm/ttm: move swapin out of page alloc backend Christian König
2020-10-25 15:40 ` [PATCH 03/13] drm/ttm: make num_pages uint32_t Christian König
2020-10-25 15:40 ` [PATCH 04/13] drm/ttm: merge ttm_dma_tt back into ttm_tt Christian König
2020-10-25 15:40 ` [PATCH 05/13] drm/ttm: new TT backend allocation pool Christian König
2020-10-25 18:35   ` kernel test robot
2020-10-25 19:01   ` kernel test robot
2020-10-25 19:01   ` [RFC PATCH] drm/ttm: ttm_pool_apply_caching() can be static kernel test robot
2020-10-26  9:56   ` [PATCH 05/13] drm/ttm: new TT backend allocation pool kernel test robot
2020-10-25 15:40 ` [PATCH 06/13] drm/ttm: wire up the new pool as default one Christian König
2020-10-25 15:40 ` [PATCH 07/13] drm/amdgpu: switch to new allocator Christian König
2020-10-25 15:40 ` [PATCH 08/13] drm/radeon: " Christian König
2020-10-25 15:40 ` [PATCH 09/13] drm/nouveau: " Christian König
2020-10-25 15:40 ` [PATCH 10/13] drm/vmwgfx: " Christian König
2020-10-25 15:40 ` [PATCH 11/13] drm/qxl: drop ttm_page_alloc.h include Christian König
2020-10-25 15:40 ` [PATCH 12/13] drm/vram_helpers: " Christian König
2020-10-25 15:41 ` [PATCH 13/13] drm/ttm: nuke old page allocator Christian König
2020-10-26  5:23 ` drm/ttm: new TT backend allocation pool Dave Airlie
2020-10-26 12:01   ` Christian König
2020-10-26 12:15     ` Daniel Vetter
2020-10-26 13:45 ` Huang Rui [this message]

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=20201026134512.GA410214@hr-amd \
    --to=ray.huang@amd.com \
    --cc=Madhav.Chauhan@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=dri-devel@lists.freedesktop.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;
as well as URLs for NNTP newsgroup(s).