Received: by 10.192.165.148 with SMTP id m20csp1986276imm; Sat, 28 Apr 2018 09:34:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpuhcmjE9+3C8RGzyNglgOTEeBv/cC9Po9U2SdP0Okoqvw/S843NoZ30YIm3Bb8/21UDd1E X-Received: by 10.98.152.203 with SMTP id d72mr6278121pfk.98.1524933270349; Sat, 28 Apr 2018 09:34:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524933270; cv=none; d=google.com; s=arc-20160816; b=oayJ4izH7+6JDurrN7y4166kWjWLUd4kl9nS9Z1wnysIL9ZFvv40jeUKHFKzBpPM4g 8z55nFHEUEzJkn+nW44kMHY03Z2OrGADSSmEAguJoya1spvTlNwZvd7ujMY9mZJPAIUp v+83XZg0biA/bFqLySVBg8+pIkxTYtb9MECsXRtvwSEmQxLfCXufuB9SsNCj4jMpfv4Q 5zZPW17O3aRLwkdpYnSsytA2bZR4QHe5qMq5XIRJgu64pQyyQoR+doI5RafG/pPiN/oM uGBtRUY2UJLLbYKdXl+EyFZ8f6EE6r+u8mnLPBEvBAKgGdbl2tyxoTBWqDBdskkDoC8u Sq4g== 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:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=88P1SPSo9Zn/BBhVcEv/WcETi9RG8QjNUu27HcdC2OY=; b=dZUu9a9gBcxrh9F4fGV+1YsYQ7q/cNqFuiZ+scgWu02fdtsviJghW9HCnpVC8k/YGg KHdLfsISn3iHwGKsA1YdXh+AAJA+9jtANMmsGNUzCuO1dYPyp3mrjSgh/j5KyHBsE495 Tijd6FZwULimhZ+q+bB6rhLmtJeB0quZSa6C6Eq+NZckiMRO2p+AK0C3tzBN6geriGMs iKNn1AjZ/pOBusVdM2EFUjZisQeWxD0/K4FkvxBSxV1iI+QxIBlr5eD4adfEjHd3uWEl csYEqnqznDIFqcD2jZE6dJBSJcbGay8199BovnWguLE1PNrwF2XiNgUoIF70DIBSf/GU J87g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Ul5t7uzP; 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 w66si3849731pfj.144.2018.04.28.09.33.32; Sat, 28 Apr 2018 09:34:30 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=Ul5t7uzP; 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 S932767AbeD1Qak (ORCPT + 99 others); Sat, 28 Apr 2018 12:30:40 -0400 Received: from mail-qk0-f193.google.com ([209.85.220.193]:42265 "EHLO mail-qk0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932552AbeD1Qaj (ORCPT ); Sat, 28 Apr 2018 12:30:39 -0400 Received: by mail-qk0-f193.google.com with SMTP id j10so3831565qke.9 for ; Sat, 28 Apr 2018 09:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=88P1SPSo9Zn/BBhVcEv/WcETi9RG8QjNUu27HcdC2OY=; b=Ul5t7uzPk79mnzPN6sNP6Y9vNs7SuKzKZ9KfJwtUn9rFOURDzIUTF7kfvdpvR+EaxD jVo1Y0WQqKqefV88M1RXzDjnExuJcYbX/byH2L4dpFQdDeAaWT7aSLtP6aQjp1hhzX1J wNLsRslGJAhNlK16fv68wAJnw1MhWRcoHL6ayDRQZxkEFYi0XA+/ADY9H9NvZk/RM3rz ULavGqWiZtzSu3hnCNK2lZttXIjAOy5oIDXzBW2oLQrS+pmK48QYl12tT68bAN5nfGlw AHYyTpg9Y96N1RqK6pcSShfIE0EyMIIGkVId+m2nbKEtwzdgwS/G8InnetqJG1Tjriun 8zAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=88P1SPSo9Zn/BBhVcEv/WcETi9RG8QjNUu27HcdC2OY=; b=O80uIUNlaxNDTFp+/Kt64CizSvym3duUrdAWxiFXYGYP62MH2BKa6XlPYjINY1J/4p 55/X83Bc7cZDNzLODeWkGDFajVtQAVljyigLUwmqx0YQesGidIZLPapy9FBEoJoHX+3h kUV0t++Z2L9A7syej2kUetH25LXxg299kzkzQi0Mwb3m+CWg2kQUgYXTYvN6M0jK1p0l gMVpnHpOYxBHceiT5AgcwkGwRLIARTYxZcgqDfbydxGm+FHopZy7IPDYTQe/kKGGVhav SkpPN7upF+TCbLLK9ZXmRsKjvV7Xmij147tc9wymyLcTyK4+QIYmh+bdNBPfwmLMnH8Y Xi8g== X-Gm-Message-State: ALQs6tBkrANSTM6l9JkSpRBxaWFpFGqs7FxqkTMxm61iuUd4mwODeFhC YfS+c5v6JSEvl0uFQH2W7fgvk640r/wjDoFCtGs= X-Received: by 10.55.178.67 with SMTP id b64mr5483713qkf.21.1524933038212; Sat, 28 Apr 2018 09:30:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.56.243 with HTTP; Sat, 28 Apr 2018 09:30:37 -0700 (PDT) In-Reply-To: <20180427130811.7642-1-michel@daenzer.net> References: <20180426150618.13470-1-michel@daenzer.net> <20180427130811.7642-1-michel@daenzer.net> From: Ilia Mirkin Date: Sat, 28 Apr 2018 12:30:37 -0400 X-Google-Sender-Auth: XmJ4I8SqIJyiw5gbIOS13yCxbSU Message-ID: Subject: Re: [PATCH v2 1/2] drm/ttm: Only allocate huge pages with new flag TTM_PAGE_FLAG_TRANSHUGE To: =?UTF-8?Q?Michel_D=C3=A4nzer?= Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , amd-gfx mailing list , dri-devel , LKML Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2018 at 9:08 AM, Michel D=C3=A4nzer wr= ote: > From: Michel D=C3=A4nzer > > 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=C3=A4nzer Both I and lots of other people, based on reports, are still seeing plenty of issues with this as late as 4.16.4. 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. 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). You're putting this behind a flag now (finally), but should it be enabled anywhere? Why is it being flipped on for amdgpu by default, despite the still-existing problems? Reverting this feature without just resetting back to the code in v4.14 is painful, but why make Joe User suffer by enabling it while you're still working out the kinks? -ilia