[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 20:13:01 -0700
Sasha Levin <levinsasha928 gmail com> writes:
> On 08/15/2012 03:08 AM, Eric W. Biederman wrote:
>>> 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.
>>
>
> Alrighty, the results are in (numbers are objects in bucket):
>
> For the 0...10000 range:
>
> Average: 78.125
> Std dev: 1.4197704151
> Min: 75
> Max: 80
>
>
> For the 1...100 range:
>
> Average: 0.78125
> Std dev: 0.5164613088
> Min: 0
> Max: 2
>
>
> For the 1000...1100 range:
>
> Average: 0.7890625
> Std dev: 0.4964812206
> Min: 0
> Max: 2
>
>
> Looks like hash_32 is pretty good with small numbers.
Yes hash_32 seems reasonable for the uid hash. With those long hash
chains I wouldn't like to be on a machine with 10,000 processes with
each with a different uid, and a processes calling setuid in the fast
path.
The uid hash that we are playing with is one that I sort of wish that
the hash table could grow in size, so that we could scale up better.
Aw well. Most of the time we only have a very small number of uids
in play, so it doesn't matter at this point.
Eric
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]