LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: "Michel Dänzer" <michel@daenzer.net>,
	"Christian König" <christian.koenig@amd.com>,
	"Ilia Mirkin" <imirkin@alum.mit.edu>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	amd-gfx mailing list <amd-gfx@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE
Date: Mon, 30 Apr 2018 20:22:29 +0200	[thread overview]
Message-ID: <361a765a-f491-4450-867e-fa88857827ee@gmail.com> (raw)
In-Reply-To: <e5256136-6da0-cc5e-9490-5a70c89dfd83@daenzer.net>

Am 30.04.2018 um 18:33 schrieb Michel Dänzer:
> On 2018-04-29 09:02 AM, Christian König wrote:
>> Am 29.04.2018 um 01:02 schrieb Michel Dänzer:
>>> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>>>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer <michel@daenzer.net>
>>>> wrote:
>>>>> From: Michel Dänzer <michel.daenzer@amd.com>
>>>>>
>>>>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
>>>>> try to allocate huge pages. However, not all drivers can take advantage
>>>>> of huge pages, but they would incur the overhead for allocating and
>>>>> freeing them anyway.
>>>>>
>>>>> Now, drivers which can take advantage of huge pages need to set the new
>>>>> flag TTM_PAGE_FLAG_TRANSHUGE to get them. Drivers not setting this flag
>>>>> no longer incur any overhead for allocating or freeing huge pages.
>>>>>
>>>>> v2:
>>>>> * Also guard swapping of consecutive pages in ttm_get_pages
>>>>> * Reword commit log, hopefully clearer now
>>>>>
>>>>> Cc: stable@vger.kernel.org
>>>>> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>>>> Both I and lots of other people, based on reports, are still seeing
>>>> plenty of issues with this as late as 4.16.4.
>>> "lots of other people", "plenty of issues" sounds a bit exaggerated from
>>> what I've seen. FWIW, while I did see the original messages myself, I
>>> haven't seen any since Christian's original fix (see below), neither
>>> with amdgpu nor radeon, even before this patch you followed up to.
>>>
>>>
>>>> Admittedly I'm on nouveau, but others have reported issues with
>>>> radeon/amdgpu as well. It's been going on since the feature was merged
>>>> in v4.15, with what seems like little investigation from the authors
>>>> introducing the feature.
>>> That's not a fair assessment. See
>>> https://bugs.freedesktop.org/show_bug.cgi?id=104082#c40 and following
>>> comments.
>>>
>>> Christian fixed the original issue in
>>> d0bc0c2a31c95002d37c3cc511ffdcab851b3256 "swiotlb: suppress warning when
>>> __GFP_NOWARN is set". Christian did his best to try and get the fix in
>>> before 4.15 final, but for reasons beyond his control, it was delayed
>>> until 4.16-rc1 and then backported to 4.15.5.
>>>
>>> Unfortunately, there was an swiotlb regression (not directly related to
>>> Christian's work) shortly after this fix, also in 4.16-rc1, which is now
>>> fixed in 4.17-rc1 and will be backported to 4.16.y.
>> And that's exactly the reason why I intentionally kept this enabled for
>> all users of the TTM DMA page pool and not put it behind a flag.
>>
>> This change has surfaced quite a number of bugs in the swiotlb code
>> which could have caused issues before. It's just that those code path
>> where never exercised massively before.
>>
>> Additional to that using huge pages is beneficial for the MM and CPU TLB
>> (not implemented yet) even when the GPU driver can't make much use of it.
> Do I understand correctly that you're against this patch?

Not completely, I've considered adding that multiple times myself.

I'm just torn apart between keeping it enabled so that the underlying 
bugs gets fixed and disabling it for a better end user experience.

But in general I would opt out for a pool configuration option, not a 
per driver flag.

> AFAIU the only benefit of huge pages with a driver which doesn't take
> advantage of them directly is "for the MM". Can you describe a bit more
> what that benefit is exactly?

When transparent huge pages are in effect we should have more huge pages 
than small pages in the system allocator.

So by enforcing allocation of small pages we fragment the huge pages 
once more and give khugepaged quite a bunch of work todo to gather them 
together into huge pages again.

> Is it expected to outweigh the cost of allocating / freeing huge pages?

Yes, and actually quite well (at least in theory).

>>> It looks like there's at least one more bug left, but it's not clear yet
>>> when that was introduced, whether it's directly related to Christian's
>>> work, or indeed what the impact is. Let's not get ahead of ourselves.
>> Well my patches surfaced the problems, but the underlying issues where
>> present even before those changes and I'm very well involved in fixing
>> the underlying issues.
>>
>> I even considered to just revert the huge page path for the DMA pool
>> allocator, but it's just that the TTM patches seem to work exactly as
>> they are intended. So that doesn't feel like doing the right thing here.
> I agree. Has anyone reported this to the DMA/SWIOTLB developers?

Yes, I fixed the original false positive messages myself with the 
swiotlb maintainer and I was CCed in fixing the recent fallout from 
Chris changes as well.

Regards,
Christian.

  reply	other threads:[~2018-04-30 18:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 15:06 [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE Michel Dänzer
2018-04-26 15:06 ` [PATCH 2/2] drm/ttm: Use GFP_TRANSHUGE_LIGHT for allocating huge pages Michel Dänzer
2018-04-29  7:04   ` Christian König
2018-04-27  2:51 ` [PATCH 1/2] drm/ttm: Add TTM_PAGE_FLAG_TRANSHUGE zhoucm1
2018-04-27  8:41   ` Michel Dänzer
2018-04-27 13:08 ` [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE Michel Dänzer
2018-04-28 16:30   ` Ilia Mirkin
2018-04-28 23:02     ` Michel Dänzer
2018-04-28 23:56       ` Ilia Mirkin
2018-05-02  8:08         ` Michel Dänzer
2018-04-29  7:02       ` Christian König
2018-04-30 16:33         ` Michel Dänzer
2018-04-30 18:22           ` Christian König [this message]
2018-04-30 23:15             ` Dave Airlie
2018-05-01 13:59               ` Michel Dänzer

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=361a765a-f491-4450-867e-fa88857827ee@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imirkin@alum.mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel@daenzer.net \
    --subject='Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE' \
    /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).