On 26/04/2017 23:22, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote:
On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
I was thinking of exactly the same thing as this patch does, u64
context id as key, u32 seqnos (wrapped in a container with
hlist_node).
#define NSYNC 32
struct intel_timeline_sync { /* kmalloc-256 slab */
struct hlist_node node;
u64 prefix;
u32 bitmap;
u32 seqno[NSYNC];
};
DECLARE_HASHTABLE(sync, 7);
If I squint, the numbers favour the idr. ;)
Hmm, it didn't take much to start running into misery with a static ht.
I know my testing is completely artificial but I am not going to be
happy with a static size, it will always be too big or too small and
never just Goldilocks.
Oh what a pity, implementation is so much smaller. What kind of misery
was it? I presume not longer below the noise floor? With more than three
buckets?
If no other choice I'll tackle the review. Hopefully won't get lost in
all the shifts, leafs, branches and prefixes. :)
Regards,
Tvrtko
P.S. GEM_STATS you mention in the other reply - what are you referring
to with that? The idea to expose queue depths and possibly more via some
interface? If so prototyping that is almost next on my TODO list.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
