From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Sasha Levin <levinsasha928@gmail.com>,
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, 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: Thu, 16 Aug 2012 10:28:22 -0400 [thread overview]
Message-ID: <20120816142821.GC29703@Krystal> (raw)
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B6FB5@saturn3.aculab.com>
* David Laight (David.Laight@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 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.
>
> Since uids are likely to be allocated in dense blocks, maybe an
> unhashed multi-level lookup scheme might be appropriate.
>
> Index an array with the low 8 (say) bits of the uid.
> Each item can be either:
> 1) NULL => free entry.
> 2) a pointer to a uid structure (check uid value).
> 3) a pointer to an array to index with the next 8 bits.
> (2) and (3) can be differentiated by the low address bit.
I'm currently experimenting with "Judy arrays", which would likely be a
good fit for this kind of use-case.
It's basically a 256-ary trie, with fixed depth that depends on the key
size, that uses various encoding (compaction) schemes to compress
internal nodes depending on their density. The original implementation
made by HP has been criticised as somewhat too complex (20k lines of
code), but I'm currently working (in my spare time) on a more elegant
solution, that supports RCU lookups and distributed locking, and uses
much simpler node compaction schemes, and focus on having good cache
locality (and minimal number of cache line hits) for lookups.
I'll be presenting my ongoing work at Plumbers, if you are interested.
Best regards,
Mathieu
> I think that is updateable with cmpxchg.
>
> Clearly this is a bad algorithm if uids are all multiples of 2^24
> but that is true or any hash function.
>
> David
>
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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-16 14:28 UTC|newest]
Thread overview: 31+ 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 ` [PATCH 01/16] hashtable: introduce a small and naive hashtable Sasha Levin
2012-08-14 23:25 ` NeilBrown
2012-08-15 0:24 ` Sasha Levin
2012-08-15 0:28 ` Tejun Heo
2012-08-14 16:24 ` [PATCH 02/16] user_ns: use new hashtable implementation Sasha Levin
2012-08-14 23:52 ` Eric W. Biederman
2012-08-15 0:47 ` Sasha Levin
2012-08-15 1:08 ` Eric W. Biederman
2012-08-15 1:35 ` Sasha Levin
2012-08-15 3:13 ` Eric W. Biederman
2012-08-15 3:31 ` Mathieu Desnoyers
2012-08-15 13:40 ` Sasha Levin
2012-08-15 8:46 ` David Laight
2012-08-16 14:28 ` Mathieu Desnoyers [this message]
2012-08-14 16:24 ` [PATCH 03/16] mm,ksm: " Sasha Levin
2012-08-14 16:24 ` [PATCH 04/16] workqueue: " Sasha Levin
2012-08-14 16:24 ` [PATCH 05/16] mm/huge_memory: " Sasha Levin
2012-08-14 16:24 ` [PATCH 06/16] tracepoint: " Sasha Levin
2012-08-14 16:24 ` [PATCH 07/16] net,9p: " Sasha Levin
2012-08-14 16:24 ` [PATCH 08/16] block,elevator: " Sasha Levin
2012-08-14 16:24 ` [PATCH 09/16] SUNRPC/cache: " Sasha Levin
2012-08-14 16:24 ` [PATCH 10/16] dlm: " Sasha Levin
2012-08-14 16:24 ` [PATCH 11/16] net,l2tp: " Sasha Levin
2012-08-14 16:24 ` [PATCH 12/16] dm: " Sasha Levin
2012-08-14 16:24 ` [PATCH 13/16] lockd: " Sasha Levin
2012-08-14 16:24 ` [PATCH 14/16] net,rds: " Sasha Levin
2012-08-14 16:24 ` [PATCH 15/16] openvswitch: " Sasha Levin
2012-08-14 16:24 ` [PATCH 16/16] tracing output: " Sasha Levin
2012-08-14 18:16 ` [PATCH 00/16] generic " 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
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=20120816142821.GC29703@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=David.Laight@ACULAB.COM \
--cc=Trond.Myklebust@netapp.com \
--cc=aarcange@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bfields@fieldses.org \
--cc=ccaulfie@redhat.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=dm-devel@redhat.com \
--cc=ebiederm@xmission.com \
--cc=edumazet@google.com \
--cc=ejt@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=ericvh@gmail.com \
--cc=fweisbec@gmail.com \
--cc=jesse@nicira.com \
--cc=josh@joshtriplett.org \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=lw@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
--cc=rds-devel@oss.oracle.com \
--cc=rostedt@goodmis.org \
--cc=snitzer@redhat.com \
--cc=teigland@redhat.com \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=venkat.x.venkatsubra@oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).