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.
Thanks, Ben On 03/28/2016 01:29 PM, Ben Greear wrote:
Hello! 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 here: https://lkml.org/lkml/2015/12/3/307 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? Thanks, Ben
-- Ben Greear <gree...@candelatech.com> Candela Technologies Inc http://www.candelatech.com
