Received: by 10.192.165.148 with SMTP id m20csp2233848imm; Sat, 28 Apr 2018 16:04:21 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpJsL/sC+145jDC9kRMY3lztfeZxmmH0/7xJR/tMDNrcKFAInq13W/tJStMGkXCBryutwWK X-Received: by 2002:a17:902:bf4b:: with SMTP id u11-v6mr7145930pls.30.1524956661161; Sat, 28 Apr 2018 16:04:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524956661; cv=none; d=google.com; s=arc-20160816; b=sRNenhkw4BSJVPB8sfPqIkagPvBGANGSg1M9ux4Mm9RaKS0a7vGhw9fGehMMfA5Lne JLRLUVPDiJe6AzWbj6aPC+yxdL6d2k0W452loWoOgia92DHeTFTlHv2afHzOeUMiPczE v0vs/XL8d50gNaazSAgmdHwSrD0oTuukiDJYr5SLMedjT//KjaWJbC7eNWHl0a8mSfr4 Ef+zDHwrxoBlqqVLzKK/CktuB2TNjWBWvVUtDjYf0q1pc4aBkMEqVFlsuiezIKrW6+rD ok6l6JQccPjKjCC1MOuarXrYP+dqbVQFrmFLDFi29ZdU2CJYtmHuyhhToWsSjKJdnkN6 sUTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=44WjT9oreMMiBOy5rbw/kVxctM0gX+U9NuQkvZStvN8=; b=HDjPDZWHucvD/0cD7cCVB5Df4falDEYTAWxw0RDXQ3eeIgXgidxau3NgfIzrRXJnV/ lENaTbA3UIGuZa8wT3jrHpvkMZPLQcM1ltynDS/i3Rsbc5kEuOeLy5iajOFJ2Hyrs8+8 X185/KfEf8RWnPE/b7OcLRPd9mFRd3Eqs7AhK3XLfp5XWqLX2qVNliTEPPTwWu4azOXH yaw+D7gjaFrMfQUtk4OZ2giI6BJ/zM/t1f3WCEpWQrVylgIWzznaYvoZJOR1O7OuUTFu 55suRy1CxOFNe/qZHeb6kS4mM5q/L/9ikHEXFwSPJshcamX+6BaY9xpKLMc3RtvpmTUA ZQQg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f9-v6si3794846pgt.625.2018.04.28.16.03.52; Sat, 28 Apr 2018 16:04:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752230AbeD1XCH (ORCPT + 99 others); Sat, 28 Apr 2018 19:02:07 -0400 Received: from mail.netline.ch ([148.251.143.178]:34848 "EHLO netline-mail3.netline.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751310AbeD1XCG (ORCPT ); Sat, 28 Apr 2018 19:02:06 -0400 Received: from localhost (localhost [127.0.0.1]) by netline-mail3.netline.ch (Postfix) with ESMTP id 99AF02A6048; Sun, 29 Apr 2018 01:02:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at netline-mail3.netline.ch Received: from netline-mail3.netline.ch ([127.0.0.1]) by localhost (netline-mail3.netline.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kMkLGKuyAqqd; Sun, 29 Apr 2018 01:02:03 +0200 (CEST) Received: from thor (145.233.60.188.dynamic.wline.res.cust.swisscom.ch [188.60.233.145]) by netline-mail3.netline.ch (Postfix) with ESMTPSA id DA4032A6046; Sun, 29 Apr 2018 01:02:02 +0200 (CEST) Received: from localhost ([::1]) by thor with esmtp (Exim 4.90_1) (envelope-from ) id 1fCYqv-0005XB-5F; Sun, 29 Apr 2018 01:02:01 +0200 Subject: Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE To: Ilia Mirkin Cc: dri-devel , =?UTF-8?Q?Christian_K=c3=b6nig?= , amd-gfx mailing list , LKML References: <20180426150618.13470-1-michel@daenzer.net> <20180427130811.7642-1-michel@daenzer.net> From: =?UTF-8?Q?Michel_D=c3=a4nzer?= Message-ID: Date: Sun, 29 Apr 2018 01:02:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-CA Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-28 06:30 PM, Ilia Mirkin wrote: > On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote: >> From: Michel Dänzer >> >> 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 > > 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. 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. > We now have *two* broken releases, v4.15 and v4.16 (anything that > spews error messages and stack traces ad-infinitum in dmesg is, by > definition, broken). I haven't seen any evidence that there's still an issue in 4.15, is there any? > You're putting this behind a flag now (finally), I wrote this patch because I realized due to some remark I happened to see you make this week on IRC that the huge page support in TTM was enabled for all drivers. Instead of making that kind of remark on IRC, it would have been more constructive, and more conducive to quick implementation, to suggest making the feature not active for drivers which don't need it in a mailing list post. At least, please do more research before making this kind of negative post. P.S. You might also want to look into whether nouveau really should be hitting swiotlb in these cases. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer