Hi On Wed, Aug 13, 2014 at 2:35 PM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> 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érôme Glisse wrote: >>>> From: Jérôme Glisse <jglisse@xxxxxxxxxx> >>>> >>>> When experiencing memory pressure we want to minimize pool size so that >>>> memory we just shrinked is not added back again just as the next thing. >>>> >>>> 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érôme, >>> >>> 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 shrinker >> callbacks to ensure we don't consume more than our fair share of available >> 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. gem->filp points to a fresh shmem file, which itself is limited like dmabuf. That should suffice, right? Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
