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.4 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 D5624C4332B for ; Tue, 24 Mar 2020 10:31:22 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A59E120775 for ; Tue, 24 Mar 2020 10:31:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=amdcloud.onmicrosoft.com header.i=@amdcloud.onmicrosoft.com header.b="Rl6KuE9Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A59E120775 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amd.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 546C089C1F; Tue, 24 Mar 2020 10:31:21 +0000 (UTC) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2079.outbound.protection.outlook.com [40.107.93.79]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1DAA289BF4 for ; Tue, 24 Mar 2020 10:31:20 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SHZPajcjF/KZUY4+eJXddzjs6LCJiZtPnN35g6IR8k5ZMPQoLC1GBrSwYePl7LPidQoloI2/8QSw9qPxdDTfUAiTVpoCYXfKGkoCyNPDchB6XbkkEhd/yy6xC1kVpQDhZRisQdQROh5Y47tpZYO/eZ99uaC8FFAWQUOU5b4cpNtkNXKaOArTbqP31rBLbmUELm+zxQYzfM3i8enZo7r5BA6knuVBgcYz6ZBVgZeQAPYpcvsl2E0o6tmG0UU9cAf2+hlXg1Z/GgpasWPacdZY+zeyMvaytkrYkJCoOUy2bpvgbnBAqH5dJSOa2JFchwydDF7rYu3FGR9Kgtiojd+qXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EI3659Sm+BqV5w+u7eJ1S3NSEdTHXQq+SGnvz9oBuxk=; b=Po6fpKnuieof81xyU+7eHUq8OpNVkCRSib7pc1nEB9l14ApS9ukFBECOv9WWavAtPaafYpKQCQI8EqGKB4QGC6ve9N84D08JUke1WaXq3d9ewSmfU35l+3UF9cNKp23ez0fXq0PEq7ZtFtlbjL027hVTAdGvGIJEYPxtBQx3MU2fKui4OJW8xNLpMJAuO801lHQoBubUZydeMdUc5PgVXeZS63Njlx8KOnTBnxdPC7dzt2JxeFNAnVrGJCiqWUAlSl7ETk6//staQN/ViXZmbfiLCCeXi6788t6J9iMOXYcL4utC/8+TY4UXO6kLo1XtgnbNyH6S+xOYsFZj3hkg2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amdcloud.onmicrosoft.com; s=selector2-amdcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EI3659Sm+BqV5w+u7eJ1S3NSEdTHXQq+SGnvz9oBuxk=; b=Rl6KuE9ZccYaP/+9z2cJs97d8vSKgb4aVeeCs+WPvtddjUigoYxCHUnsTNPuIPTH5uWQvxPNH2dYLCGZ/zc0J5cvArmoIVT6lmJxAm4SUN+UHKCil5gelDQ4RWBBKVXl5ZceUHEtVOnCkONC1756mA/OCLrLadqheimcbNOH4uI= Received: from DM5PR12MB1578.namprd12.prod.outlook.com (2603:10b6:4:e::7) by DM5PR12MB1387.namprd12.prod.outlook.com (2603:10b6:3:6c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Tue, 24 Mar 2020 10:31:18 +0000 Received: from DM5PR12MB1578.namprd12.prod.outlook.com ([fe80::50f0:a148:4f52:701f]) by DM5PR12MB1578.namprd12.prod.outlook.com ([fe80::50f0:a148:4f52:701f%11]) with mapi id 15.20.2835.021; Tue, 24 Mar 2020 10:31:18 +0000 From: "Koenig, Christian" To: =?iso-8859-1?Q?Thomas_Hellstr=F6m_=28VMware=29?= Subject: Re: Separate pull request? WAS: [PATCH v6 0/9] Huge page-table entries for TTM Thread-Topic: Separate pull request? WAS: [PATCH v6 0/9] Huge page-table entries for TTM Thread-Index: AQHV8g+2hJkFvufeEEqndLeD8JMe96hXosOAgAAH0g0= Date: Tue, 24 Mar 2020 10:31:18 +0000 Message-ID: <0d04f17d-1c8e-47dc-8191-cc9022f64853@email.android.com> References: <20200304102840.2801-1-thomas_os@shipmail.org>, <23b212f3-d5cf-6315-23af-b084dcbbe958@shipmail.org> In-Reply-To: <23b212f3-d5cf-6315-23af-b084dcbbe958@shipmail.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Christian.Koenig@amd.com; x-originating-ip: [2a02:908:1252:fb60:d499:4acd:5ca0:7c60] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 62ac97aa-b511-4d5f-3cb8-08d7cfde7d44 x-ms-traffictypediagnostic: DM5PR12MB1387: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:73; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(966005)(66476007)(66574012)(66946007)(76116006)(53546011)(4326008)(91956017)(64756008)(9686003)(2906002)(6512007)(5660300002)(6506007)(66446008)(66556008)(316002)(45080400002)(478600001)(31686004)(31696002)(6486002)(6916009)(8936002)(86362001)(186003)(81156014)(8676002)(81166006)(71200400001)(14583001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR12MB1387; H:DM5PR12MB1578.namprd12.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; received-spf: None (protection.outlook.com: amd.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oVOBL32ie1hDsp7xs3gQpFsig56YyHZv0tkKzfkV+/nnQ33PVeHkpE8u/abCgdRfR1s4FUReP/EcQBB7CDDIgGL0z3myYHn/NisAOpF7I/AxPF/m1DX+FQYcRdH9aEISLyEg1kPmurIOtKjWQdOQzuq5VMsiMdDPRzyDlLUu/6adQUufcZIBoI+0FkseO17r6yfS2LHtz+3SLz4xFCfqCxORXRY4ZeS2Tp2jW+qBurXvgcGH2yAkdDXGqZuNzQ8VnzGJ7L75w2j8yv5jSZYnkvya1w0UqVcw41GjrCZHEsBvuKd0r8weKOV2pelSLmsLXlF8xq3+AxCcAsMiETxg6mNiikswN/zZa+TBqyLPxTYg3ibPWF6e9VRAg1FJn+Vj8DQFEVYHZLn3z2B/NuAOrFQ/q72MjJRPddayT4L9T8tGkGUF4uSgDIpHHy1CZV6Fe7RWTJZqkMuBhd2rAVkM8ZgNFRprq4DfBh9+5wlCv+56UysBXC2W94/X0ECVVZX7n5q1kZ9gXmQZsnPjNPyE9w== x-ms-exchange-antispam-messagedata: bxo82boZy3hJkj4cQAGXRlMtFMI5SJoS4czqEAd02ejEr9Rt9/vVUeE3/YYuIdJnBzySWy2lnL+Kv9TDFSp8YTkS4Z+oQ0CUDfTQc2TQROSlS+hlBIuSEn/eUgh6z9U+3Aak1ClZ0mAoVSxfvsuTIX6NX+PhAqa28J520Miu73hNEQi56zwUANx5DmOFYCRPppiSFqLENjYVi4v2a8r4Hw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62ac97aa-b511-4d5f-3cb8-08d7cfde7d44 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 10:31:18.5978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Qjfd4WXztbrz28OkOpRw5wRkwGkwDu9rmJDWERHJck7bLBm9P7jzAXCVk+WUOLRq X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1387 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "dri-devel@lists.freedesktop.org" Content-Type: multipart/mixed; boundary="===============1404995495==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1404995495== Content-Language: de-DE Content-Type: multipart/alternative; boundary="_000_0d04f17d1c8e47dc8191cc9022f64853emailandroidcom_" --_000_0d04f17d1c8e47dc8191cc9022f64853emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yeah, sure go ahead. It's just that I am out of office because of COVID-19 and won't be able to = help if it goes up in flames :) Cheers, Christian Am 24.03.2020 11:03 schrieb "Thomas Hellstr=F6m (VMware)" : On 3/4/20 11:28 AM, Thomas Hellstr=F6m (VMware) wrote: > In order to reduce CPU usage [1] and in theory TLB misses this patchset e= nables > huge- and giant page-table entries for TTM and TTM-enabled graphics drive= rs. > > Patch 1 and 2 introduce a vma_is_special_huge() function to make the mm c= ode > take the same path as DAX when splitting huge- and giant page table entri= es, > (which currently means zapping the page-table entry and rely on re-faulti= ng). > > Patch 3 makes the mm code split existing huge page-table entries > on huge_fault fallbacks. Typically on COW or on buffer-objects that want > write-notify. COW and write-notification is always done on the lowest > page-table level. See the patch log message for additional considerations= . > > Patch 4 introduces functions to allow the graphics drivers to manipulate > the caching- and encryption flags of huge page-table entries without ugly > hacks. > > Patch 5 implements the huge_fault handler in TTM. > This enables huge page-table entries, provided that the kernel is configu= red > to support transhuge pages, either by default or using madvise(). > However, they are unlikely to be inserted unless the kernel buffer object > pfns and user-space addresses align perfectly. There are various options > here, but since buffer objects that reside in system pages typically star= t > at huge page boundaries if they are backed by huge pages, we try to enfor= ce > buffer object starting pfns and user-space addresses to be huge page-size > 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 code > 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 for > 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 drive= r. > 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 buffe= r > object tail will use smaller size page-table entries and thus no memory > overhead occurs. Drivers that want to pay the memory overhead price need = to > implement their own scheme to inflate buffer-object sizes. > > PMD size huge page-table-entries have been tested with vmwgfx and found t= o > work well both with system memory backed and IO memory backed buffer obje= cts. > > PUD size giant page-table-entries have seen limited (fault and COW) testi= ng > using a modified kernel (to support 1GB page allocations) and a fake vmwg= fx > 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=F6= nig) > * Rebased on the vmwgfx emulated coherent memory functionality. That reba= se > adds patch 5. > Changes since v1: > * Make the new TTM range manager vmwgfx-specific. (Christian K=F6nig) > * 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=F6nig) > * 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 ar= ch > 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 o= n a > vmwgfx-enabled kernel without the patch series: > > 4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624maxresid= ent)k > 0inputs+0outputs (0major+640077minor)pagefaults 0swaps > > and with the patch series: > > 1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656maxresid= ent)k > 0inputs+0outputs (0major+20079minor)pagefaults 0swaps > > A consistent number of reduced graphics page-faults can be seen with norm= al > graphics applications, but due to the aggressive buffer object caching in > vmwgfx user-space drivers the CPU time reduction is within the error marg= inal. > > #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]); > > map =3D mmap(NULL, c_arg.size, PROT_READ | PROT_WRITE, MAP_SHARED,= 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]); > } > > close(fd); > } > > Cc: Andrew Morton > Cc: Michal Hocko > Cc: "Matthew Wilcox (Oracle)" > Cc: "Kirill A. Shutemov" > Cc: Ralph Campbell > Cc: "J=E9r=F4me Glisse" > Cc: "Christian K=F6nig" > Cc: Dan Williams > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists= .freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=3D02%7C01%7Cchri= stian.koenig%40amd.com%7Cbd52811a941244ba8b9908d7cfda99cb%7C3dd8961fe4884e6= 08e11a82d994e183d%7C0%7C0%7C637206410124474022&sdata=3D642fi4213qtdqtYC= FfPNesOIDGmoYBuR4PeEzWMyfKE%3D&reserved=3D0 Hi, Christian, I think this should be OK to merge now. Is it OK if I ask Dave to pull this separately? Thanks, Thomas --_000_0d04f17d1c8e47dc8191cc9022f64853emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yeah, sure go ahead.

It's just that I am out of office because of COVID-19 and= won't be able to help if it goes up in flames :)

Cheers,
Christian

Am 24.03.2020 11:03 schrieb "Thomas Hells= tr=F6m (VMware)" <thomas_os@shipmail.org>:


On 3/4/20 11:28 AM, Thomas Hellstr=F6m (VMware) wrote:
> In order to reduce CPU usage [1] and in theory TLB misses this patchse= t enables
> huge- and giant page-table entries for TTM and TTM-enabled graphics dr= ivers.
>
> Patch 1 and 2 introduce a vma_is_special_huge() function to make the m= m code
> take the same path as DAX when splitting huge- and giant page table en= tries,
> (which currently means zapping the page-table entry and rely on re-fau= lting).
>
> Patch 3 makes the mm code split existing huge page-table entries
> on huge_fault fallbacks. Typically on COW or on buffer-objects that wa= nt
> write-notify. COW and write-notification is always done on the lowest<= br> > page-table level. See the patch log message for additional considerati= ons.
>
> Patch 4 introduces functions to allow the graphics drivers to manipula= te
> the caching- and encryption flags of huge page-table entries without u= gly
> hacks.
>
> Patch 5 implements the huge_fault handler in TTM.
> This enables huge page-table entries, provided that the kernel is conf= igured
> to support transhuge pages, either by default or using madvise().
> However, they are unlikely to be inserted unless the kernel buffer obj= ect
> pfns and user-space addresses align perfectly. There are various optio= ns
> here, but since buffer objects that reside in system pages typically s= tart
> at huge page boundaries if they are backed by huge pages, we try to en= force
> buffer object starting pfns and user-space addresses to be huge page-s= ize
> aligned if their size exceeds a huge page-size. If pud-size transhuge<= br> > ("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 co= de
> to handle that correctly.
>
> Patch 7 implements a drm helper to align user-space addresses accordin= g
> to the above scheme, if possible.
>
> Patch 8 implements a TTM range manager for vmwgfx that does the same f= or
> 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 dr= iver.
> 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 bu= ffer
> object tail will use smaller size page-table entries and thus no memor= y
> overhead occurs. Drivers that want to pay the memory overhead price ne= ed to
> implement their own scheme to inflate buffer-object sizes.
>
> PMD size huge page-table-entries have been tested with vmwgfx and foun= d to
> work well both with system memory backed and IO memory backed buffer o= bjects.
>
> PUD size giant page-table-entries have seen limited (fault and COW) te= sting
> using a modified kernel (to support 1GB page allocations) and a fake v= mwgfx
> 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= =F6nig)
> * Rebased on the vmwgfx emulated coherent memory functionality. That r= ebase
>    adds patch 5.
> Changes since v1:
> * Make the new TTM range manager vmwgfx-specific. (Christian K=F6nig)<= br> > * 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=F6nig) > * 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 ru= n on a
> vmwgfx-enabled kernel without the patch series:
>
> 4.78user 6.02system 0:10.91elapsed 99%CPU (0avgtext+0avgdata 1624m= axresident)k
> 0inputs+0outputs (0major+640077minor)pagefaults 0swaps
>
> and with the patch series:
>
> 1.71user 3.60system 0:05.40elapsed 98%CPU (0avgtext+0avgdata 1656m= axresident)k
> 0inputs+0outputs (0major+20079minor)pagefaults 0swaps
>
> A consistent number of reduced graphics page-faults can be seen with n= ormal
> graphics applications, but due to the aggressive buffer object caching= in
> vmwgfx user-space drivers the CPU time reduction is within the error m= arginal.
>
> #include <unistd.h>
> #include <string.h>
> #include <sys/mman.h>
> #include <xf86drm.h>
>
> 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};<= br> >      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_IOC= TL_MODE_CREATE_DUMB, &c_arg);
>        checkerr(fd, argv[0]);
>
>        m_arg.handle =3D c_arg.handl= e;
>        ret =3D drmIoctl(fd, DRM_IOC= TL_MODE_MAP_DUMB, &m_arg);
>        checkerr(fd, argv[0]);
>       
>        map =3D mmap(NULL, c_arg.siz= e, PROT_READ | PROT_WRITE, MAP_SHARED, fd,
>            = ;   m_arg.offset);
>        checkerr(map =3D=3D MAP_FAIL= ED ? -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.handl= e;
>        ret =3D drmIoctl(fd, DRM_IOC= TL_MODE_DESTROY_DUMB, &d_arg);
>        checkerr(ret, argv[0]);
>      }
>     
>      close(fd);
> }
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org> > Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com= >
> Cc: Ralph Campbell <rcampbell@nvidia.com>
> Cc: "J=E9r=F4me Glisse" <jglisse@redhat.com>
> Cc: "Christian K=F6nig" <christian.koenig@amd.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flists.f= reedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&amp;data=3D02%7C01%7Cch= ristian.koenig%40amd.com%7Cbd52811a941244ba8b9908d7cfda99cb%7C3dd8961fe4884= e608e11a82d994e183d%7C0%7C0%7C637206410124474022&amp;sdata=3D642fi4213q= tdqtYCFfPNesOIDGmoYBuR4PeEzWMyfKE%3D&amp;reserved=3D0

Hi, Christian,

I think this should be OK to merge now. Is it OK if I ask Dave to pull
this separately?

Thanks,

Thomas


--_000_0d04f17d1c8e47dc8191cc9022f64853emailandroidcom_-- --===============1404995495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1404995495==--