summaryrefslogtreecommitdiff
path: root/arch/m68k/Kconfig.cpu
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2016-09-26 20:44:14 (GMT)
committerDaniel Vetter <daniel.vetter@ffwll.ch>2016-10-04 06:23:07 (GMT)
commit077675c1e8a193a6355d4a7c8c7bf63be310b472 (patch)
tree1126f18b7accec717e1fc6d4862fa344a6d0a1b5 /arch/m68k/Kconfig.cpu
parent188af070d4d20474cba4d42b4eaf728ba116f418 (diff)
downloadlinux-077675c1e8a193a6355d4a7c8c7bf63be310b472.tar.xz
drm: Convert prime dma-buf <-> handle to rbtree
Currently we use a linear walk to lookup a handle and return a dma-buf, and vice versa. A long overdue TODO task is to convert that to a hashtable. Since the initial implementation of dma-buf/prime, we now have resizeable hashtables we can use (and now a future task is to RCU enable the lookup!). However, this patch opts to use an rbtree instead to provide O(lgN) lookups (and insertion, deletion). rbtrees were chosen over using the RCU backed resizable hashtable to firstly avoid the reallocations (rbtrees can be embedded entirely within the parent struct) and to favour simpler code with predictable worst case behaviour. In simple testing, the difference between using the constant lookup and insertion of the rhashtable and the rbtree was less than 10% of the wall time (igt/benchmarks/prime_lookup) - both are dramatic improvements over the existing linear lists. v2: Favour rbtree over rhashtable Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94631 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160926204414.23222-1-chris@chris-wilson.co.uk
Diffstat (limited to 'arch/m68k/Kconfig.cpu')
0 files changed, 0 insertions, 0 deletions