From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753412AbeASGBv (ORCPT ); Fri, 19 Jan 2018 01:01:51 -0500 Received: from mail-dm3nam03on0085.outbound.protection.outlook.com ([104.47.41.85]:58181 "EHLO NAM03-DM3-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752153AbeASGBn (ORCPT ); Fri, 19 Jan 2018 01:01:43 -0500 Authentication-Results: spf=none (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; kvack.org; dkim=none (message not signed) header.d=none;kvack.org; dmarc=permerror action=none header.from=amd.com; Subject: Re: [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers To: Andrey Grodzovsky , , , , CC: References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com> From: Chunming Zhou Message-ID: Date: Fri, 19 Jan 2018 14:01:32 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.34.1.3] X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:165.204.84.17;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(10009020)(39860400002)(396003)(39380400002)(346002)(376002)(2980300002)(428003)(189003)(199004)(7736002)(58126008)(105586002)(16576012)(2870700001)(6666003)(478600001)(2950100002)(31686004)(16526018)(6246003)(110136005)(64126003)(59450400001)(31696002)(316002)(106466001)(53936002)(2201001)(356003)(81166006)(5660300001)(4326008)(81156014)(8936002)(305945005)(65826007)(77096007)(8676002)(575784001)(76176011)(72206003)(67846002)(83506002)(2486003)(104016004)(26005)(47776003)(229853002)(68736007)(23676004)(97736004)(50466002)(2906002)(36756003)(65956001)(65806001)(6116002)(3846002)(2101003);DIR:OUT;SFP:1101;SCL:1;SRVR:BN6PR12MB1444;H:SATLEXCHOV02.amd.com;FPR:;SPF:None;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;DM3NAM03FT043;1:YVt+/81TBSJspFcg2VhzZTR31fTajdKWwY6DswKPlhXqCwkyj4WOrwdin3Um5W1UX6Uj4TPUh+vo4PnKmIbdjoIRwxIxarnO6OIvDR9mpI+GtjRUXpi/OWKAQmkcRf+K X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7283b251-0be2-44e6-4553-08d55f021bc6 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(7020095)(4652020)(5600026)(4604075)(2017052603307)(7153060)(7193020);SRVR:BN6PR12MB1444; X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1444;3:wJura0TOEznOfwsDbR6qmjaTMKoqyUFeBm/8+be/Ieeb86o6DIZeildc+DbTlMTfwHy2ZKtZtRJhIVj0edhyyJANZgWCEICU03W4Nulk0cYfsf296yJ6PyqJ4YB17QwIRfKbHztH60ehwH2XaxKXuiq+dmZruzE/S/c3Ddu1DRUuni7V1HCXf6lISch4ge2Y5KCP3rHHodb8j9UUVxSDyCAguOEdDatpqJpMHLR7n48oFmKazlbq+bkoRn0NCJ20NjqFETUetrqLZryq4Zvb77nvAWdUkfyq94OAIUXaEN3sJOP7cl+azas9xLQhXpMgGFE2AWNn1NNEOA39csBsvBDCPepDG5OIMBPgsxHXebI=;25:Kkvm6ct4fvBNHBcJZYiolVLADIVFgr6h5t2K9tFb/JjKYJbHH8gk8EkwR+iNaSsI46AFTixCjS4SPii91pAcsAnT/zgD1scD7AvwU8WT5mHdJagQ+LBtvi1eyTLjgflwrtDH5Tsjet2EtsTkB9iEePVj/hl3kbp/wgixKsXkhndMPkkT5nuz5rDVt8KdcpdRhzA5VJtPgaoTCQ9Td5bwV+GwqpZLohcyjWILpQlxOC7KnX0O95CpQJIuHqs8bb3TltLHy5bOa+8RtXyT4NCanaXO8JVR6sQBfnCckw/Gzr6pCVlqLbE2OJ7Srnu7MptJNuXiRTGFCW1n3SuJcqjX1A== X-MS-TrafficTypeDiagnostic: BN6PR12MB1444: X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1444;31:xj6a5nznPZM+hFDX8y6X5sOQVNQ07adxIjGhqR0UqU5mgAIf6F1JK6jC8jSu8e1PaFECiLdbfWXZa34jzD8mXgLWbX9BFFy7SzySzQMD+lZnq1RswmGoQKW1Yrx+0xk1p8hyv2+OKEvTxgxNw2gwGmrZLGAxsB0B696ogoUvDogCepiiyG6SACi4W4hCYEwwmyw+M+6rBHXyAygHbu7ey/bg3JqtloVgQMWLWP1V84Y=;20:pnDiCLf24FN9LDToAK7nU6NzpyTgaxXzwlbV0NKC4z6YyBCDGgwDE/CiGvDjFPUivk3wLjSiI5nRARu7Kl6MpH8l7dmuXQW6vT09RwzdlEgWi/OBCeVP2of7errWwevPphvDS8T8auf1ELJ4dXt8rMGWvzF9AujdROo+f6Vfzf2uXdYibpXbT+RoO7cTQ+qGPhIReX/y0GDhxIxxH7SuRhaXIET90IjVFUQBPJelN8M4Ht3lvueUjUCJmovbupu8U/aVy69dDY8AJ/3u76LM/G1cqHVaNshyPpwo9s+o0CI9576W0tpRm/1alhyB41NqXUDLebUAkA6h9WHCbIk5syaBio1Xh3nNk88egoOqsOJoA7wUOjaCAI2UWCw/oZ+3FHuOAXvzfiZ4dKlK5DNeWmwyq5iYVUkdnN76oDldpNfleOL7+tXo3mMsNbGPz4T6/OCI3zkwxsxcGkuESTBC/o2bSO04QoDEnDusPpUK/bTWlPUcpS9K3yXZGtTUFdHh X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(767451399110); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(2400072)(944501161)(93006095)(93003095)(10201501046)(6055026)(6041268)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011);SRVR:BN6PR12MB1444;BCL:0;PCL:0;RULEID:(100000803101)(100110400095);SRVR:BN6PR12MB1444; X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1444;4:i3X6IDfhZn3AdwU3Nx08Ghls591mv4I0zPZQuYdoVE4nqL0LXvlVWxt4td5qKsegdGAlo9InptMYe5ZhXPWEGM20uZgubJXbA0XkXgJawhAXRarng9KaJ5tlWIr2ICwXbEn+Oy5/w83pb2FbNfq9uCFa1uIFXVey+kbY0aYOwEGGTC8ijASZb+uTJOxC87pwRo8UL0uk42Zq9DOZfnn4Ybzz1r15uYShYbWx7Iud/R6u0bijFbSp3kQZDyXsojS2YeYfcUp5ivfeqgcrgkILySfZiQ2AYYge7zrsA3bpcRh4K5qG3gn0GwSYGYhpKREZ X-Forefront-PRVS: 0557CBAD84 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjEyTUIxNDQ0OzIzOngvUU1KalhPOVVnUTh0dGgrM3MrWDBDSDVt?= =?utf-8?B?YUUzekZsdkIvKzZmaVRhNkhza05CeFlySHhmWXVPZ3N0ckhEV0hBb1JCT0h6?= =?utf-8?B?Mlp5SENVZHBia0o2Vmk4RHVobXY4Z1hzQ3NNL28xRjk4NEttVGY3c3FBTU51?= =?utf-8?B?bGQzaE8yeGQwZVNBU2Z3aWk5MDhOZmRIWlRCN0w4UDVkTHlnUlVLeVovYmxD?= =?utf-8?B?Y2tpbDlaNTFjb1Q5RGFDNWM1WTlaYzRuZHYyRXNSZlRKa3NVOVdzQmkxa2tR?= =?utf-8?B?WnhTMDBLVWNESEFEZTRtNTNROGdJSGhzTjhaaENRVkNTWGhBL2Y2Mkg2MkVS?= =?utf-8?B?dWhNTDYvaDc1T3FrSmlSUGNaRmdSUnVwcWlxOGhvWVk1ZTNtcExsOUl0ckg2?= =?utf-8?B?bHVOM2JNdVBRWklaMDJIUS9NS1ZZODdld1ArSFVhcDdXZjhoSVZxdnB2WCtB?= =?utf-8?B?QWFwU0xJWVVZRnh4eHdsNlRiM20xY1hhdkNJVkoxWUl5MXBYd2RSS1V5NXkr?= =?utf-8?B?OGVqd3VhK3o3K1EzTStkcXNVeXM3ZXcvdjR6MVk0ajNIQ1JkTUFPMFlER0kz?= =?utf-8?B?UGVCTkRBZVVBZGVXOWZROE9uelNSOEtueHZSWkV3WTFTbS82blE0TU1FNVc1?= =?utf-8?B?ZUV5ajJFd2YrRUYrRjRaRzNJeElSVlhqd29EZ3orcERGYWxIU1B6Mm4zU2Fq?= =?utf-8?B?aGFWc0tBWFdXT2oxTXF4VHBSQSswU1hUY0FhZzFWMUVQREVqMndRTW5mMzFR?= =?utf-8?B?ckZzVGJHcDBtRWU1Nm02M2Q2VVk0YkFTSUpZekhBVzdGQjRSNU1XNG5jb3ZE?= =?utf-8?B?QVNIWm10MkhLTEN0cXhxbXJBbUVVMHZ4WU1sMG5iVGxmcXhrZmpDbmZXckEw?= =?utf-8?B?L1lYSXdWU1czYlVEVEQ0Vk9mSXFhejVOUlNuM1h5eTRTUkdZSzRiSUU0alhF?= =?utf-8?B?akovUkNkNDR0ZncwQ3U4STUrTnZackl1NlNPMDZ3b2lYbmVpTVNSU2RkVVFl?= =?utf-8?B?N3FrN2hPNUJ5emFkVXpITzlLa1M0MWl6aHRjOGtsU1JyT0szcloxb3F4czJp?= =?utf-8?B?L1B4UEhFKzI0Sm1pVjFOODZ4ajNCSStnWjdHQVZlR25Eai90TE5neFpLZTVX?= =?utf-8?B?eTl1UTkyNEgxckxWNXc0bDdWZWdmaEswSDVucXUvdGx5S213ZmVQY1Nicy9x?= =?utf-8?B?L2traVQ2Ykh6Y2tGSm4xVWlHS2orY2NoYlVwSW04ckxsWUQzWWZuMDR2aDRM?= =?utf-8?B?T3l3NGRaRzJrQjNxcG5Zd01uRjJkU256dEJLZEMwTkxxL3ZGOGx4N3VqV2tZ?= =?utf-8?B?ZnE3YWh6Tmtwa2Fvbm9nQ0hYaExkc3RycTMxRktucUw1TnYwUTk4YVN6U3lp?= =?utf-8?B?dTZFWVpxNHQzU1E5bE9JTDN0QmJJQzBCY2hoUFhPT0FTUTlqeGxQeVFNdGRi?= =?utf-8?B?a2RvQTNTNC9FSTYzTlVHdmxKTlBDKzM1anpEMkk5ZERoTEVQL2lyNkErSVp2?= =?utf-8?B?alVma1RLbTdNMGN4L0RZeDZNd0FkWXM5NzA0VnlRRS9YRkgxK0dVUTg5djZN?= =?utf-8?B?U1oyajZqaU10ZllDU0VEMGFrSElTZXJ2eXJOdWZ1RWRGdXNCZmVLYVR1UkY5?= =?utf-8?B?L1llQ3lGU3pGNHhnME1oTzFoK1lSc2hXbHlWZHZZS0g5L1ZCaWU3ZkMyenpJ?= =?utf-8?B?UFBHUzlySVFKUTVRckpuZ3U1bXN3YmtCL0FRZGhwci9xNzNLT0hIM24zaC9o?= =?utf-8?B?LzBqM0RYS3h4cnpSYlAyc3NXU2gxeXNYNE9vWXdIbjlJbmc2U0hKeGNNODVX?= =?utf-8?B?QkJrWHV6bDRGSHU1T3JzU3pzT3Bzdzd1dDNWMDJDTDBzbUE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1444;6:QWeXh2KmSDPv09EdH1ItaTjIWuoJ4jwx1a4/FEAKlQr0JhTxtUB6h46ahZAt+o7wQUOE5OT+xw8/Z6bMvPgYD96ZhyNnuoj/vDM5PU5MkLbn5gjXkYSSDJcGYxZ5U2sil46a6TgJZeBkjp/USBGlpljZqqVyVMwZJGCv/YjN/6k9Hpgb0MdFIj/SUQaSCKb8zc5XKU+ewRXEQRwFTHUCq83ip9AGfAzIg7OOBSTZ7V4eTIzctlBgvyQNfNg6elVv/vyEey7YN5lktxp9vqKlyeuKh+CkrjrcQ25HNX/LTTw3QpJwzFNvEgcheAFS5mdAyEkpNlPa/dzVx8myUKzWHzGgvPXuOo0ylcB+2IC9tGY=;5:fNd4XCSIwIpn33yrnHSMpVPPgXIkIWqEzdAi8qocsN8GeyRCKGHxR/4B1YqGI0tQHHOssDUBlelJcnS3m67KL3mGELoBGnEUjwtQ79/QYsPUGqm8yd058GbNxcdXAbkr4wFV6T6CzYWvbOKhneUhcRenadD16cHDzQKep3KPkqI=;24:/duMAyV8A97B1eb8YnUW338rBRC5UkXlqHwoHI7RySwjs3xspMPSpqrXUri89LLcEcj2s0QnCAFoaxwkXHXCOuLLBbdyyTqhZE5l24UGDJg=;7:84EEj4SqC+yZcmB6zOf4bSoqwSxdFUjGo/kE3TiZxIMZTwppIFX3lFCTIt5P8wni4LTd/5Mh6HsDg2a2dnjrA1XlXx3l87onfMwvadlRyowi5h272qaGtajHOhLyr/ssR0NtVgHkQnt/kBWrA+iWm0vVjAp6csE2Obiu2rRF3nbKHksRYtWIn1TWFnTAMtPXWLU1dwkDXJWI3d+wSkIptiRPnedaTdr9S8HXB/TmpllrlbxUvfLzQf2bQEx27DH6 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;BN6PR12MB1444;20:8E3JkgiUUeiXwatfgzGh1YOWxcWYNgaY99C8nrPfZl3OSjHl+elKCQiQWHu5HXVwmWw0iSYFkyWRv+V9UzFUwcQYKeKP/Rc47u8NYGyCIv1xP5OLFBxn6mDxSPycepe92kkRYOJySjfENxzCpAU5U36LZfn9y/uOmmkLQKNXtip0SQvw+BQA6XM5bjYpvTrbP2e9Pkuoy2ZC3IGbYai9x0omo90IxPGq8/bfb0iCdiHbX0jBI0xkw6WIbr49uj0G X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2018 06:01:40.1157 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7283b251-0be2-44e6-4553-08d55f021bc6 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXCHOV02.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1444 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018年01月19日 00:47, Andrey Grodzovsky wrote: > Large amounts of VRAM are usually not CPU accessible, so they are not mapped > into the processes address space. But since the device drivers usually support > swapping buffers from VRAM to system memory we can still run into an out of > memory situation when userspace starts to allocate to much. > > This patch gives the OOM another hint which process is > holding how many resources. > > Signed-off-by: Andrey Grodzovsky > --- > drivers/gpu/drm/drm_file.c | 12 ++++++++++++ > drivers/gpu/drm/drm_gem.c | 8 ++++++++ > include/drm/drm_file.h | 4 ++++ > 3 files changed, 24 insertions(+) > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > index b3c6e99..626cc76 100644 > --- a/drivers/gpu/drm/drm_file.c > +++ b/drivers/gpu/drm/drm_file.c > @@ -747,3 +747,15 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e) > spin_unlock_irqrestore(&dev->event_lock, irqflags); > } > EXPORT_SYMBOL(drm_send_event); > + > +long drm_oom_badness(struct file *f) > +{ > + > + struct drm_file *file_priv = f->private_data; > + > + if (file_priv) > + return atomic_long_read(&file_priv->f_oom_badness); > + > + return 0; > +} > +EXPORT_SYMBOL(drm_oom_badness); > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 01f8d94..ffbadc8 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -264,6 +264,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) > drm_gem_remove_prime_handles(obj, file_priv); > drm_vma_node_revoke(&obj->vma_node, file_priv); > > + atomic_long_sub(obj->size >> PAGE_SHIFT, > + &file_priv->f_oom_badness); > + > drm_gem_object_handle_put_unlocked(obj); > > return 0; > @@ -299,6 +302,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) > idr_remove(&filp->object_idr, handle); > spin_unlock(&filp->table_lock); > > + atomic_long_sub(obj->size >> PAGE_SHIFT, &filp->f_oom_badness); > + > return 0; > } > EXPORT_SYMBOL(drm_gem_handle_delete); > @@ -417,6 +422,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, > } > > *handlep = handle; > + > + atomic_long_add(obj->size >> PAGE_SHIFT, > + &file_priv->f_oom_badness); For VRAM case, it should be counted only when vram bo is evicted to system memory. For example, vram total is 8GB, system memory total is 8GB, one application allocates 7GB vram and 7GB system memory, which is allowed, but if following your idea, then this application will be killed by OOM, right? Regards, David Zhou > return 0; > > err_revoke: > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h > index 0e0c868..ac3aa75 100644 > --- a/include/drm/drm_file.h > +++ b/include/drm/drm_file.h > @@ -317,6 +317,8 @@ struct drm_file { > > /* private: */ > unsigned long lock_count; /* DRI1 legacy lock count */ > + > + atomic_long_t f_oom_badness; > }; > > /** > @@ -378,4 +380,6 @@ void drm_event_cancel_free(struct drm_device *dev, > void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e); > void drm_send_event(struct drm_device *dev, struct drm_pending_event *e); > > +long drm_oom_badness(struct file *f); > + > #endif /* _DRM_FILE_H_ */ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 608936B0069 for ; Fri, 19 Jan 2018 01:01:44 -0500 (EST) Received: by mail-pg0-f72.google.com with SMTP id f5so828643pgp.18 for ; Thu, 18 Jan 2018 22:01:44 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0072.outbound.protection.outlook.com. [104.47.41.72]) by mx.google.com with ESMTPS id m16si7688648pgc.628.2018.01.18.22.01.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Jan 2018 22:01:43 -0800 (PST) Subject: Re: [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com> From: Chunming Zhou Message-ID: Date: Fri, 19 Jan 2018 14:01:32 +0800 MIME-Version: 1.0 In-Reply-To: <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: To: Andrey Grodzovsky , linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org Cc: Christian.Koenig@amd.com On 2018a1'01ae??19ae?JPY 00:47, Andrey Grodzovsky wrote: > Large amounts of VRAM are usually not CPU accessible, so they are not mapped > into the processes address space. But since the device drivers usually support > swapping buffers from VRAM to system memory we can still run into an out of > memory situation when userspace starts to allocate to much. > > This patch gives the OOM another hint which process is > holding how many resources. > > Signed-off-by: Andrey Grodzovsky > --- > drivers/gpu/drm/drm_file.c | 12 ++++++++++++ > drivers/gpu/drm/drm_gem.c | 8 ++++++++ > include/drm/drm_file.h | 4 ++++ > 3 files changed, 24 insertions(+) > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > index b3c6e99..626cc76 100644 > --- a/drivers/gpu/drm/drm_file.c > +++ b/drivers/gpu/drm/drm_file.c > @@ -747,3 +747,15 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e) > spin_unlock_irqrestore(&dev->event_lock, irqflags); > } > EXPORT_SYMBOL(drm_send_event); > + > +long drm_oom_badness(struct file *f) > +{ > + > + struct drm_file *file_priv = f->private_data; > + > + if (file_priv) > + return atomic_long_read(&file_priv->f_oom_badness); > + > + return 0; > +} > +EXPORT_SYMBOL(drm_oom_badness); > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 01f8d94..ffbadc8 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -264,6 +264,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) > drm_gem_remove_prime_handles(obj, file_priv); > drm_vma_node_revoke(&obj->vma_node, file_priv); > > + atomic_long_sub(obj->size >> PAGE_SHIFT, > + &file_priv->f_oom_badness); > + > drm_gem_object_handle_put_unlocked(obj); > > return 0; > @@ -299,6 +302,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) > idr_remove(&filp->object_idr, handle); > spin_unlock(&filp->table_lock); > > + atomic_long_sub(obj->size >> PAGE_SHIFT, &filp->f_oom_badness); > + > return 0; > } > EXPORT_SYMBOL(drm_gem_handle_delete); > @@ -417,6 +422,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, > } > > *handlep = handle; > + > + atomic_long_add(obj->size >> PAGE_SHIFT, > + &file_priv->f_oom_badness); For VRAM case, it should be counted only when vram bo is evicted to system memory. For example, vram total is 8GB, system memory total is 8GB, one application allocates 7GB vram and 7GB system memory, which is allowed, but if following your idea, then this application will be killed by OOM, right? Regards, David Zhou > return 0; > > err_revoke: > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h > index 0e0c868..ac3aa75 100644 > --- a/include/drm/drm_file.h > +++ b/include/drm/drm_file.h > @@ -317,6 +317,8 @@ struct drm_file { > > /* private: */ > unsigned long lock_count; /* DRI1 legacy lock count */ > + > + atomic_long_t f_oom_badness; > }; > > /** > @@ -378,4 +380,6 @@ void drm_event_cancel_free(struct drm_device *dev, > void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e); > void drm_send_event(struct drm_device *dev, struct drm_pending_event *e); > > +long drm_oom_badness(struct file *f); > + > #endif /* _DRM_FILE_H_ */ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chunming Zhou Subject: Re: [PATCH 3/4] drm/gem: adjust per file OOM badness on handling buffers Date: Fri, 19 Jan 2018 14:01:32 +0800 Message-ID: References: <1516294072-17841-1-git-send-email-andrey.grodzovsky@amd.com> <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <1516294072-17841-4-git-send-email-andrey.grodzovsky@amd.com> Content-Language: en-US Sender: owner-linux-mm@kvack.org To: Andrey Grodzovsky , linux-kernel@vger.kernel.org, linux-mm@kvack.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org Cc: Christian.Koenig@amd.com List-Id: dri-devel@lists.freedesktop.org On 2018年01月19日 00:47, Andrey Grodzovsky wrote: > Large amounts of VRAM are usually not CPU accessible, so they are not mapped > into the processes address space. But since the device drivers usually support > swapping buffers from VRAM to system memory we can still run into an out of > memory situation when userspace starts to allocate to much. > > This patch gives the OOM another hint which process is > holding how many resources. > > Signed-off-by: Andrey Grodzovsky > --- > drivers/gpu/drm/drm_file.c | 12 ++++++++++++ > drivers/gpu/drm/drm_gem.c | 8 ++++++++ > include/drm/drm_file.h | 4 ++++ > 3 files changed, 24 insertions(+) > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > index b3c6e99..626cc76 100644 > --- a/drivers/gpu/drm/drm_file.c > +++ b/drivers/gpu/drm/drm_file.c > @@ -747,3 +747,15 @@ void drm_send_event(struct drm_device *dev, struct drm_pending_event *e) > spin_unlock_irqrestore(&dev->event_lock, irqflags); > } > EXPORT_SYMBOL(drm_send_event); > + > +long drm_oom_badness(struct file *f) > +{ > + > + struct drm_file *file_priv = f->private_data; > + > + if (file_priv) > + return atomic_long_read(&file_priv->f_oom_badness); > + > + return 0; > +} > +EXPORT_SYMBOL(drm_oom_badness); > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c > index 01f8d94..ffbadc8 100644 > --- a/drivers/gpu/drm/drm_gem.c > +++ b/drivers/gpu/drm/drm_gem.c > @@ -264,6 +264,9 @@ drm_gem_object_release_handle(int id, void *ptr, void *data) > drm_gem_remove_prime_handles(obj, file_priv); > drm_vma_node_revoke(&obj->vma_node, file_priv); > > + atomic_long_sub(obj->size >> PAGE_SHIFT, > + &file_priv->f_oom_badness); > + > drm_gem_object_handle_put_unlocked(obj); > > return 0; > @@ -299,6 +302,8 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle) > idr_remove(&filp->object_idr, handle); > spin_unlock(&filp->table_lock); > > + atomic_long_sub(obj->size >> PAGE_SHIFT, &filp->f_oom_badness); > + > return 0; > } > EXPORT_SYMBOL(drm_gem_handle_delete); > @@ -417,6 +422,9 @@ drm_gem_handle_create_tail(struct drm_file *file_priv, > } > > *handlep = handle; > + > + atomic_long_add(obj->size >> PAGE_SHIFT, > + &file_priv->f_oom_badness); For VRAM case, it should be counted only when vram bo is evicted to system memory. For example, vram total is 8GB, system memory total is 8GB, one application allocates 7GB vram and 7GB system memory, which is allowed, but if following your idea, then this application will be killed by OOM, right? Regards, David Zhou > return 0; > > err_revoke: > diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h > index 0e0c868..ac3aa75 100644 > --- a/include/drm/drm_file.h > +++ b/include/drm/drm_file.h > @@ -317,6 +317,8 @@ struct drm_file { > > /* private: */ > unsigned long lock_count; /* DRI1 legacy lock count */ > + > + atomic_long_t f_oom_badness; > }; > > /** > @@ -378,4 +380,6 @@ void drm_event_cancel_free(struct drm_device *dev, > void drm_send_event_locked(struct drm_device *dev, struct drm_pending_event *e); > void drm_send_event(struct drm_device *dev, struct drm_pending_event *e); > > +long drm_oom_badness(struct file *f); > + > #endif /* _DRM_FILE_H_ */ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org