Switch user_ns to use the new hashtable implementation. This reduces the amount
of
generic unrelated code in user_ns.
Signed-off-by: Sasha Levin
---
kernel/user.c | 33 +
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/kernel/user.c
Sasha Levin writes:
> On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
>> Sasha Levin 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
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
> Sasha Levin 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
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
Sasha Levin levinsasha...@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
Sasha Levin levinsasha...@gmail.com writes:
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
Sasha Levin levinsasha...@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
Switch user_ns to use the new hashtable implementation. This reduces the amount
of
generic unrelated code in user_ns.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
kernel/user.c | 33 +
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git
* David Laight (david.lai...@aculab.com) wrote:
> > 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
* David Laight (david.lai...@aculab.com) wrote:
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
On 08/15/2012 05:31 AM, Mathieu Desnoyers wrote:
> * Eric W. Biederman (ebied...@xmission.com) wrote:
>> Sasha Levin 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...1
>> into a hashtable
> 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
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
On 08/15/2012 05:31 AM, Mathieu Desnoyers wrote:
* Eric W. Biederman (ebied...@xmission.com) wrote:
Sasha Levin levinsasha...@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...1
into a hashtable
* Eric W. Biederman (ebied...@xmission.com) wrote:
> Sasha Levin 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...1
> >>> > into a hashtable which uses 7 bits (just like user_ns) and post the
Sasha Levin 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...1
>>> > into a hashtable which uses 7 bits (just like user_ns) and post the
>>> > distribution
>>> > we'll get.
>> That won't hurt. I
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...1
>> > 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
Sasha Levin writes:
> On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
>> Sasha Levin 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
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
> Sasha Levin 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
Sasha Levin 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
Switch user_ns to use the new hashtable implementation. This reduces the amount
of
generic unrelated code in user_ns.
Signed-off-by: Sasha Levin
---
kernel/user.c | 33 +
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/kernel/user.c
Switch user_ns to use the new hashtable implementation. This reduces the amount
of
generic unrelated code in user_ns.
Signed-off-by: Sasha Levin levinsasha...@gmail.com
---
kernel/user.c | 33 +
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git
Sasha Levin levinsasha...@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
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
Sasha Levin levinsasha...@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
Sasha Levin levinsasha...@gmail.com writes:
On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
Sasha Levin levinsasha...@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
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...1
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
Sasha Levin levinsasha...@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...1
into a hashtable which uses 7 bits (just like user_ns) and post the
distribution
we'll get.
That won't hurt. I
* Eric W. Biederman (ebied...@xmission.com) wrote:
Sasha Levin levinsasha...@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...1
into a hashtable which uses 7 bits (just like user_ns) and post
26 matches
Mail list logo
