From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org,
rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org,
mingo-X9Un+BFzKDI@public.gmane.org,
aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org,
axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org,
agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
neilb-l3A5Bk7waGM@public.gmane.org,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
teigland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org,
bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org,
ejt-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org,
lw-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org
Subject: Re: [PATCH 02/16] user_ns: use new hashtable implementation
Date: Tue, 14 Aug 2012 18:08:09 -0700 [thread overview]
Message-ID: <87393phshy.fsf@xmission.com> (raw)
In-Reply-To: <502AF184.4010907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> (Sasha Levin's message of "Wed, 15 Aug 2012 02:47:00 +0200")
Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 08/15/2012 01:52 AM, Eric W. Biederman wrote:
>> Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, tj@kernel.org,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, paul.gortmaker@windriver.com,
davem@davemloft.net, rostedt@goodmis.org, mingo@elte.hu,
aarcange@redhat.com, ericvh@gmail.com, netdev@vger.kernel.org,
josh@joshtriplett.org, eric.dumazet@gmail.com,
mathieu.desnoyers@efficios.com, axboe@kernel.dk, agk@redhat.com,
dm-devel@redhat.com, neilb@suse.de, ccaulfie@redhat.com,
teigland@redhat.com, Trond.Myklebust@netapp.com,
bfields@fieldses.org, fweisbec@gmail.com, jesse@nicira.com,
venkat.x.venkatsubra@oracle.com, ejt@redhat.com,
snitzer@redhat.com, edumazet@google.com,
linux-nfs@vger.kernel.org, dev@openvswitch.org,
rds-devel@oss.oracle.com, lw@cn.fujitsu.com
Subject: Re: [PATCH 02/16] user_ns: use new hashtable implementation
Date: Tue, 14 Aug 2012 18:08:09 -0700 [thread overview]
Message-ID: <87393phshy.fsf@xmission.com> (raw)
In-Reply-To: <502AF184.4010907@gmail.com> (Sasha Levin's message of "Wed, 15 Aug 2012 02:47:00 +0200")
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
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Sasha Levin <levinsasha928@gmail.com>
Cc: torvalds@linux-foundation.org, tj@kernel.org,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, paul.gortmaker@windriver.com,
davem@davemloft.net, rostedt@goodmis.org, mingo@elte.hu,
aarcange@redhat.com, ericvh@gmail.com, netdev@vger.kernel.org,
josh@joshtriplett.org, eric.dumazet@gmail.com,
mathieu.desnoyers@efficios.com, axboe@kernel.dk, agk@redhat.com,
dm-devel@redhat.com, neilb@suse.de, ccaulfie@redhat.com,
teigland@redhat.com, Trond.Myklebust@netapp.com,
bfields@fieldses.org, fweisbec@gmail.com, jesse@nicira.com,
venkat.x.venkatsubra@oracle.com, ejt@redhat.com,
snitzer@redhat.com, edumazet@google.com,
linux-nfs@vger.kernel.org, dev@openvswitch.org,
rds-devel@oss.oracle.com, lw@cn.fujitsu.com
Subject: Re: [PATCH 02/16] user_ns: use new hashtable implementation
Date: Tue, 14 Aug 2012 18:08:09 -0700 [thread overview]
Message-ID: <87393phshy.fsf@xmission.com> (raw)
In-Reply-To: <502AF184.4010907@gmail.com> (Sasha Levin's message of "Wed, 15 Aug 2012 02:47:00 +0200")
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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2012-08-15 1:08 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 16:24 [PATCH 00/16] generic hashtable implementation Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 02/16] user_ns: use new " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 23:52 ` Eric W. Biederman
2012-08-14 23:52 ` Eric W. Biederman
[not found] ` <87txw5hw0s.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-08-15 0:47 ` Sasha Levin
2012-08-15 0:47 ` Sasha Levin
2012-08-15 0:47 ` Sasha Levin
[not found] ` <502AF184.4010907-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-08-15 1:08 ` Eric W. Biederman [this message]
2012-08-15 1:08 ` Eric W. Biederman
2012-08-15 1:08 ` Eric W. Biederman
2012-08-15 1:35 ` Sasha Levin
2012-08-15 1:35 ` Sasha Levin
[not found] ` <502AFCD5.6070104-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-08-15 3:13 ` Eric W. Biederman
2012-08-15 3:13 ` Eric W. Biederman
2012-08-15 3:13 ` Eric W. Biederman
2012-08-15 3:31 ` Mathieu Desnoyers
2012-08-15 3:31 ` Mathieu Desnoyers
2012-08-15 13:40 ` Sasha Levin
2012-08-15 13:40 ` Sasha Levin
2012-08-15 13:40 ` Sasha Levin
[not found] ` <87obmchmpu.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-08-15 8:46 ` David Laight
2012-08-15 8:46 ` David Laight
2012-08-15 8:46 ` David Laight
[not found] ` <AE90C24D6B3A694183C094C60CF0A2F6026B6FB5-CgBM+Bx2aUAnGFn1LkZF6NBPR1lH4CV8@public.gmane.org>
2012-08-16 14:28 ` Mathieu Desnoyers
2012-08-16 14:28 ` Mathieu Desnoyers
2012-08-16 14:28 ` Mathieu Desnoyers
2012-08-18 21:52 ` Sasha Levin
2012-08-18 22:21 ` Eric W. Biederman
2012-08-14 16:24 ` [PATCH 03/16] mm,ksm: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
[not found] ` <1344961490-4068-1-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-08-14 16:24 ` [PATCH 01/16] hashtable: introduce a small and naive hashtable Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
[not found] ` <1344961490-4068-2-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-08-14 23:25 ` NeilBrown
2012-08-14 23:25 ` NeilBrown
[not found] ` <20120815092523.00a909ef-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2012-08-15 0:24 ` Sasha Levin
2012-08-15 0:24 ` Sasha Levin
2012-08-15 0:24 ` Sasha Levin
2012-08-15 0:28 ` Tejun Heo
2012-08-15 0:28 ` Tejun Heo
2012-08-14 16:24 ` [PATCH 04/16] workqueue: use new hashtable implementation Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 05/16] mm/huge_memory: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 06/16] tracepoint: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 08/16] block, elevator: " Sasha Levin
2012-08-14 16:24 ` [PATCH 08/16] block,elevator: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 09/16] SUNRPC/cache: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 10/16] dlm: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 11/16] net, l2tp: " Sasha Levin
2012-08-14 16:24 ` [PATCH 11/16] net,l2tp: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 12/16] dm: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 13/16] lockd: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 15/16] openvswitch: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 16/16] tracing output: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 07/16] net,9p: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 16:24 ` [PATCH 14/16] net,rds: " Sasha Levin
2012-08-14 16:24 ` Sasha Levin
2012-08-14 18:16 ` [PATCH 00/16] generic " J. Bruce Fields
2012-08-14 18:16 ` J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2012-08-19 0:52 [PATCH v2 " Sasha Levin
2012-08-19 0:52 ` [PATCH 02/16] user_ns: use new " Sasha Levin
2012-08-19 0:52 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87393phshy.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA@public.gmane.org \
--cc=aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=agk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \
--cc=bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org \
--cc=ccaulfie-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org \
--cc=dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=ejt-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=ericvh-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org \
--cc=josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org \
--cc=levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lw-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org \
--cc=mingo-X9Un+BFzKDI@public.gmane.org \
--cc=neilb-l3A5Bk7waGM@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org \
--cc=rds-devel-N0ozoZBvEnrZJqsBc5GL+g@public.gmane.org \
--cc=rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org \
--cc=snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=teigland-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.