[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH 02/16] user_ns: use new hashtable implementation
- From: ebiederm xmission com (Eric W. Biederman)
- To: Sasha Levin <levinsasha928 gmail com>
- Cc: snitzer redhat com, fweisbec gmail com, Trond Myklebust netapp com, bfields fieldses org, paul gortmaker windriver com, dm-devel redhat com, agk redhat com, aarcange redhat com, rds-devel oss oracle com, eric dumazet gmail com, venkat x venkatsubra oracle com, ccaulfie redhat com, mingo elte hu, dev openvswitch org, jesse nicira com, josh joshtriplett org, rostedt goodmis org, lw cn fujitsu com, mathieu desnoyers efficios com, axboe kernel dk, linux-nfs vger kernel org, edumazet google com, linux-mm kvack org, netdev vger kernel org, linux-kernel vger kernel org, ejt redhat com, tj kernel org, teigland redhat com, akpm linux-foundation org, torvalds linux-foundation org, davem davemloft net
- Subject: Re: [dm-devel] [PATCH 02/16] user_ns: use new hashtable implementation
- Date: Tue, 14 Aug 2012 18:08:09 -0700
Sasha Levin <levinsasha928 gmail com> writes:
> On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
>> Sasha Levin <levinsasha928 gmail com> writes:
>>
>>> Switch user_ns to use the new hashtable implementation. This reduces the amount of
>>> generic unrelated code in user_ns.
>>
>> Two concerns here.
>> 1) When adding a new entry you recompute the hash where previously that
>> was not done. I believe that will slow down adding of new entries.
>
> I figured that the price for the extra hashing isn't significant since hash_32
> is just a multiplication and a shift.
>
> I'll modify the code to calculate the key just once.
Honestly I don't know either way, but it seemed a shame to give up a
common and trivial optimization.
>> 2) Using hash_32 for uids is an interesting choice. hash_32 discards
>> the low bits. Last I checked for uids the low bits were the bits
>> that were most likely to be different and had the most entropy.
>>
>> I'm not certain how multiplying by the GOLDEN_RATION_PRIME_32 will
>> affect things but I would be surprised if it shifted all of the
>> randomness from the low bits to the high bits.
>
> "Is hash_* good enough for our purpose?" - I was actually surprised that no one
> raised that question during the RFC and assumed it was because everybody agreed
> that it's indeed good enough.
>
> I can offer the following: I'll write a small module that will hash 1...10000
> into a hashtable which uses 7 bits (just like user_ns) and post the distribution
> we'll get.
That won't hurt. I think 1-100 then 1000-1100 may actually be more
representative. Not that I would mind seeing the larger range.
Especially since I am in the process of encouraging the use of more
uids.
> If the results of the above will be satisfactory we can avoid the discussion
> about which hash function we should really be using. If not, I guess now is a
> good time for that :)
Yes. A small emperical test sounds good.
Eric
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]