From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7AFFC2BB1D for ; Mon, 16 Mar 2020 12:32:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8F112205ED for ; Mon, 16 Mar 2020 12:32:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=shipmail.org header.i=@shipmail.org header.b="fKVGsSJ4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8F112205ED Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=shipmail.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2296E6B0003; Mon, 16 Mar 2020 08:32:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DAF36B0005; Mon, 16 Mar 2020 08:32:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F0106B0007; Mon, 16 Mar 2020 08:32:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0199.hostedemail.com [216.40.44.199]) by kanga.kvack.org (Postfix) with ESMTP id E86B76B0003 for ; Mon, 16 Mar 2020 08:32:21 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id B45D58248D52 for ; Mon, 16 Mar 2020 12:32:21 +0000 (UTC) X-FDA: 76601163282.01.hole72_88c3186c2c91c X-HE-Tag: hole72_88c3186c2c91c X-Filterd-Recvd-Size: 9871 Received: from pio-pvt-msa1.bahnhof.se (pio-pvt-msa1.bahnhof.se [79.136.2.40]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Mon, 16 Mar 2020 12:32:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa1.bahnhof.se (Postfix) with ESMTP id DA5B43F58C; Mon, 16 Mar 2020 13:32:17 +0100 (CET) Authentication-Results: pio-pvt-msa1.bahnhof.se; dkim=pass (1024-bit key; unprotected) header.d=shipmail.org header.i=@shipmail.org header.b="fKVGsSJ4"; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at bahnhof.se Received: from pio-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fZSjgeWs2My; Mon, 16 Mar 2020 13:32:16 +0100 (CET) Received: from mail1.shipmail.org (h-205-35.A357.priv.bahnhof.se [155.4.205.35]) (Authenticated sender: mb878879) by pio-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 4CBFA3F57C; Mon, 16 Mar 2020 13:32:09 +0100 (CET) Received: from linlap1.host.shipmail.org (unknown [94.191.152.149]) by mail1.shipmail.org (Postfix) with ESMTPSA id E1CAE36044C; Mon, 16 Mar 2020 13:32:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=shipmail.org; s=mail; t=1584361929; bh=Q0mPn8cn4O4F32gfQXBKeCHhXjCZbWpQMUUrzHQpRXs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fKVGsSJ44ckNJZyG5zVRIZps2Jj6tpleF6qPCpDgqppNwatVwrlF7IsNNdgaXB9V9 or14c5W0A4QJb6bKH5VrVlWWItm4ITgXjiyyx/uY8MKV5/iBgU+oI+DWErKw4h3Vwq b0v7L84nhM9Lmt5tunNUjUFt8i7G1kvM3+L9Yd3o= Subject: Ack to merge through DRM? WAS [PATCH v6 0/9] Huge page-table entries for TTM To: linux-mm@kvack.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Andrew Morton Cc: Ralph Campbell , Michal Hocko , pv-drivers@vmware.com, Dan Williams , "Matthew Wilcox (Oracle)" , =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , linux-graphics-maintainer@vmware.com, =?UTF-8?Q?Christian_K=c3=b6nig?= , "Kirill A. Shutemov" References: <20200304102840.2801-1-thomas_os@shipmail.org> From: =?UTF-8?Q?Thomas_Hellstr=c3=b6m_=28VMware=29?= Organization: VMware Inc. Message-ID: <9eb1acd3-cded-65f0-ed75-10173dc3a41c@shipmail.org> Date: Mon, 16 Mar 2020 13:32:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20200304102840.2801-1-thomas_os@shipmail.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/4/20 11:28 AM, Thomas Hellstr=C3=B6m (VMware) wrote: > In order to reduce CPU usage [1] and in theory TLB misses this patchset= enables > huge- and giant page-table entries for TTM and TTM-enabled graphics dri= vers. > > Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm= code > take the same path as DAX when splitting huge- and giant page table ent= ries, > (which currently means zapping the page-table entry and rely on re-faul= ting). > > Patch 3 makes the mm code split existing huge page-table entries > on huge_fault fallbacks. Typically on COW or on buffer-objects that wan= t > write-notify. COW and write-notification is always done on the lowest > page-table level. See the patch log message for additional consideratio= ns. > > Patch 4 introduces functions to allow the graphics drivers to manipulat= e > the caching- and encryption flags of huge page-table entries without ug= ly > hacks. > > Patch 5 implements the huge_fault handler in TTM. > This enables huge page-table entries, provided that the kernel is confi= gured > to support transhuge pages, either by default or using madvise(). > However, they are unlikely to be inserted unless the kernel buffer obje= ct > pfns and user-space addresses align perfectly. There are various option= s > here, but since buffer objects that reside in system pages typically st= art > at huge page boundaries if they are backed by huge pages, we try to enf= orce > buffer object starting pfns and user-space addresses to be huge page-si= ze > aligned if their size exceeds a huge page-size. If pud-size transhuge > ("giant") pages are enabled by the arch, the same holds for those. > > Patch 6 implements a specialized huge_fault handler for vmwgfx. > The vmwgfx driver may perform dirty-tracking and needs some special cod= e > to handle that correctly. > > Patch 7 implements a drm helper to align user-space addresses according > to the above scheme, if possible. > > Patch 8 implements a TTM range manager for vmwgfx that does the same fo= r > graphics IO memory. This may later be reused by other graphics drivers > if necessary. > > Patch 9 finally hooks up the helpers of patch 7 and 8 to the vmwgfx dri= ver. > A similar change is needed for graphics drivers that want a reasonable > likelyhood of actually using huge page-table entries. > > If a buffer object size is not huge-page or giant-page aligned, > its size will NOT be inflated by this patchset. This means that the buf= fer > object tail will use smaller size page-table entries and thus no memory > overhead occurs. Drivers that want to pay the memory overhead price nee= d to > implement their own scheme to inflate buffer-object sizes. > > PMD size huge page-table-entries have been tested with vmwgfx and found= to > work well both with system memory backed and IO memory backed buffer ob= jects. > > PUD size giant page-table-entries have seen limited (fault and COW) tes= ting > using a modified kernel (to support 1GB page allocations) and a fake vm= wgfx > TTM memory type. The vmwgfx driver does otherwise not support 1GB-size = IO > memory resources. > > Comments and suggestions welcome. > Thomas > > Changes since RFC: > * Check for buffer objects present in contigous IO Memory (Christian K=C3= =B6nig) > * Rebased on the vmwgfx emulated coherent memory functionality. That re= base > adds patch 5. > Changes since v1: > * Make the new TTM range manager vmwgfx-specific. (Christian K=C3=B6nig= ) > * Minor fixes for configs that don't support or only partially support > transhuge pages. > Changes since v2: > * Minor coding style and doc fixes in patch 5/9 (Christian K=C3=B6nig) > * Patch 5/9 doesn't touch mm. Remove from the patch title. > Changes since v3: > * Added reviews and acks > * Implemented ugly but generic ttm_pgprot_is_wrprotecting() instead of = arch > specific code. > Changes since v4: > * Added timings (Andrew Morton) > * Updated function documentation (Andrew Morton) > Changes since v6: > * Fix drm build error with !CONFIG_MMU > > [1] > The below test program generates the following gnu time output when run= on a > vmwgfx-enabled kernel without the patch series: > > 4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxres= ident)k > 0inputs+0outputs (0major+640077minor)pagefaults 0swaps > > and with the patch series: > > 1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxres= ident)k > 0inputs+0outputs (0major+20079minor)pagefaults 0swaps > > A consistent number of reduced graphics page-faults can be seen with no= rmal > graphics applications, but due to the aggressive buffer object caching = in > vmwgfx user-space drivers the CPU time reduction is within the error ma= rginal. > > #include > #include > #include > #include > > static void checkerr(int ret, const char *name) > { > if (ret < 0) { > perror(name); > exit(-1); > } > } > > int main(int agc, const char *argv[]) > { > struct drm_mode_create_dumb c_arg =3D {0}; > struct drm_mode_map_dumb m_arg =3D {0}; > struct drm_mode_destroy_dumb d_arg =3D {0}; > int ret, i, fd; > void *map; > > fd =3D open("/dev/dri/card0", O_RDWR); > checkerr(fd, argv[0]); > > for (i =3D 0; i < 10000; ++i) { > c_arg.bpp =3D 32; > c_arg.width =3D 1024; > c_arg.height =3D 1024; > ret =3D drmIoctl(fd, DRM_IOCTL_MODE_CREATE_DUMB, &c_arg); > checkerr(fd, argv[0]); > > m_arg.handle =3D c_arg.handle; > ret =3D drmIoctl(fd, DRM_IOCTL_MODE_MAP_DUMB, &m_arg); > checkerr(fd, argv[0]); > =20 > map =3D mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARE= D, fd, > m_arg.offset); > checkerr(map =3D=3D MAP_FAILED ? -1 : 0, argv[0]); > > (void) madvise((void *) map, c_arg.size, MADV_HUGEPAGE); > memset(map, 0x67, c_arg.size); > munmap(map, c_arg.size); > > d_arg.handle =3D c_arg.handle; > ret =3D drmIoctl(fd, DRM_IOCTL_MODE_DESTROY_DUMB, &d_arg); > checkerr(ret, argv[0]); > } > =20 > close(fd); > } > > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Matthew Wilcox (Oracle)" > Cc: "Kirill A. Shutemov" > Cc: Ralph Campbell > Cc: "J=C3=A9r=C3=B4me Glisse" > Cc: "Christian K=C3=B6nig" > Cc: Dan Williams > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Andrew, would it be possible to have an ack for merge using a DRM tree=20 for the -mm patches? Thanks, Thomas