From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: GEM memory DOS (WAS Re: [PATCH 3/3] drm/ttm: under memory pressure minimize the size of memory pool) Date: Wed, 13 Aug 2014 15:01:08 +0200 Message-ID: <20140813130108.GA10500@phenom.ffwll.local> References: <1407901926-24516-1-git-send-email-j.glisse@gmail.com> <1407901926-24516-4-git-send-email-j.glisse@gmail.com> <53EB2A91.3000804@vmware.com> <20140813104246.GP10500@phenom.ffwll.local> <53EB5BA8.3010206@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by gabe.freedesktop.org (Postfix) with ESMTP id 060CC89F8E for ; Wed, 13 Aug 2014 06:00:56 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so11255717wes.17 for ; Wed, 13 Aug 2014 06:00:56 -0700 (PDT) Content-Disposition: inline In-Reply-To: <53EB5BA8.3010206@vmware.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Thomas Hellstrom Cc: Konrad Rzeszutek Wilk , Michel =?iso-8859-1?Q?D=E4nzer?= , dri-devel@lists.freedesktop.org, =?iso-8859-1?B?Suly9G1l?= Glisse List-Id: dri-devel@lists.freedesktop.org On Wed, Aug 13, 2014 at 02:35:52PM +0200, Thomas Hellstrom wrote: > On 08/13/2014 12:42 PM, Daniel Vetter wrote: > > On Wed, Aug 13, 2014 at 11:06:25AM +0200, Thomas Hellstrom wrote: > >> On 08/13/2014 05:52 AM, J=E9r=F4me Glisse wrote: > >>> From: J=E9r=F4me Glisse > >>> > >>> When experiencing memory pressure we want to minimize pool size so th= at > >>> memory we just shrinked is not added back again just as the next thin= g. > >>> > >>> This will divide by 2 the maximum pool size for each device each time > >>> the pool have to shrink. The limit is bumped again is next allocation > >>> happen after one second since the last shrink. The one second delay is > >>> obviously an arbitrary choice. > >> J=E9r=F4me, > >> > >> I don't like this patch. It adds extra complexity and its usefulness is > >> highly questionable. > >> There are a number of caches in the system, and if all of them added > >> some sort of voluntary shrink heuristics like this, we'd end up with > >> impossible-to-debug unpredictable performance issues. > >> > >> We should let the memory subsystem decide when to reclaim pages from > >> caches and what caches to reclaim them from. > > Yeah, artificially limiting your cache from growing when your shrinker > > gets called will just break the equal-memory pressure the core mm uses = to > > rebalance between all caches when workload changes. In i915 we let > > everything grow without artificial bounds and only rely upon the shrink= er > > callbacks to ensure we don't consume more than our fair share of availa= ble > > memory overall. > > -Daniel > = > Now when you bring i915 memory usage up, Daniel, > I can't refrain from bringing up the old user-space unreclaimable kernel > memory issue, for which gem open is a good example ;) Each time > user-space opens a gem handle, some un-reclaimable kernel memory is > allocated, for which there is no accounting, so theoretically I think a > user can bring a system to unusability this way. > = > Typically there are various limits on unreclaimable objects like this, > like open file descriptors, and IIRC the kernel even has an internal > limit on the number of struct files you initialize, based on the > available system memory, so dma-buf / prime should already have some > sort of protection. Oh yeah, we have zero cgroups limits or similar stuff for gem allocations, so there's not really a way to isolate gpu memory usage in a sane way for specific processes. But there's also zero limits on actual gpu usage itself (timeslices or whatever) so I guess no one asked for this yet. My comment really was about balancing mm users under the assumption that they're all unlimited. -Daniel -- = Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch