On Sat, Aug 10, 2013 at 05:36:07PM +0200, Marek Olšák wrote: > On Sat, Aug 10, 2013 at 5:09 PM, Christian König > <deathsim...@vodafone.de> wrote: > > Am 10.08.2013 15:53, schrieb Marek Olšák: > > > >> The RCU approach sounds good, but you can never know if 16 is enough. > >> We should release the buffer once it is full and allocate a new one. > >> The cache bufmgr in the winsys will assure there won't be any buffer > >> allocation overhead - it would work kinda a like a ring of buffers. > > > > > > Are you sure of that? The overhead of allocating a new buffer was what > > always looked so unfriendly to me with this approach. > > Absolutely. We've had this optimization since 2010 or so. As long as > you use winsys->buffer_create(use_reusable_pool=TRUE), you're fine. A > deleted buffer is added to a list of deleted buffers and if nobody > reclaims it, it will be released after 1 second. During that 1 second, > the buffer must first become idle and then anybody can reclaim it with > the same buffer_create call. If the buffer had been mapped before, > it's still mapped, so there is even no map-buffer overhead. This is a > crucial part of our driver stack that makes vertex uploading so > efficient. Don't underestimate the Radeon winsys. :)
Just an fyi how we do that for libdrm_intel: We have an madv ioctl, and every buffer in the allocation cache is marked purgeable. When memory gets tight the kernel can drop the backing storage on the floor right away for such buffers (and we preferrentially reap such objects from our shrinker). When reusing such a buffer libdrm calls madv(WILLNEED) to make sure the buffer is still around. If it got reaped libdrm cleans up the entire cache and checks for other reaped buffer objects. With this you don't need tunables like the 1s delay you're using and instead cache size is directly driven by vm pressure. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev