Re: Question on rhashtable in worst-case scenario.

From: Ben Greear
Date: Tue Mar 29 2016 - 12:16:53 EST

Looks like rhashtable has too much policy in it to properly deal with
cases where there are too many hash collisions, so I am going to work on
reverting it's use in mac80211.


On 03/28/2016 01:29 PM, Ben Greear wrote:

I have a use case for mac80211 where I create multiple stations to
the same remote peer MAC address.

I'm seeing cases where the rhashtable logic is returning -16 (EBUSY)
on insert (see sta_info_hash_add).
This is with the 4.4.6+ (plus local patches) kernel, and it has the patch mentioned

If I understand the code properly, my use case is going to be worst-case scenario,
where all of my items in the hash have the same key (peer mac addr).

I have my own secondary hash to handle most of my hot-path lookups, but I still need
the main hash to at least function in a linear-search manner.

Any idea what I can do to get rid of the EBUSY return code problem, or how
to debug it further?


Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc