From: Linus Torvalds <torvalds@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Sasha Levin <levinsasha928@gmail.com>,
Josh Triplett <josh@joshtriplett.org>, Tejun Heo <tj@kernel.org>,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, paul.gortmaker@windriver.com
Subject: Re: [RFC 1/4] hashtable: introduce a small and naive hashtable
Date: Thu, 2 Aug 2012 10:32:13 -0700 [thread overview]
Message-ID: <CA+55aFw_dwO5ZOuaz9eDxgnTZFDGVZKSLUTm5Fn99faALxxJRQ@mail.gmail.com> (raw)
In-Reply-To: <87fw851c3d.fsf@xmission.com>
On Thu, Aug 2, 2012 at 9:40 AM, Eric W. Biederman <ebiederm@xmission.com> wrote:
>
> For a trivial hash table I don't know if the abstraction is worth it.
> For a hash table that starts off small and grows as big as you need it
> the incent to use a hash table abstraction seems a lot stronger.
I'm not sure growing hash tables are worth it.
In the dcache layer, we have an allocated-at-boot-time sizing thing,
and I have been playing around with a patch that makes the hash table
statically sized (and pretty small). And it actually speeds things up!
A statically allocated hash-table with a fixed size is quite
noticeably faster, because you don't have those extra indirect reads
of the base/size that are in the critical path to the actual lookup.
So for the dentry code I tried a small(ish) direct-mapped fixed-size
"L1 hash" table that then falls back to the old dynamically sized one
when it misses ("main memory"), and it really does seem to work really
well.
The reason it's not committed in my tree is that the filling of the
small L1 hash is racy for me right now (I don't want to take any locks
for filling the small one, and I haven't figured out how to fill it
racelessly without having to add the sequence number to the hash table
itself, which would make it annoyingly bigger).
Anyway, what I really wanted to bring up was the fact that static hash
tables of a fixed size are really quite noticeably faster. So I would
say that Sasha's patch to make *that* case easy actually sounds nice,
rather than making some more complicated case that is fundamentally
slower and more complicated.
Linus
--
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-02 17:32 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 18:05 [RFC 0/4] generic hashtable implementation Sasha Levin
2012-07-31 18:05 ` [RFC 1/4] hashtable: introduce a small and naive hashtable Sasha Levin
2012-07-31 18:23 ` Tejun Heo
2012-07-31 20:31 ` Sasha Levin
2012-08-01 18:19 ` Sasha Levin
2012-08-01 18:21 ` Tejun Heo
2012-08-01 18:24 ` Sasha Levin
2012-08-01 18:27 ` Tejun Heo
2012-08-01 19:06 ` Sasha Levin
2012-08-01 20:24 ` Tejun Heo
2012-08-01 22:41 ` Sasha Levin
2012-08-01 22:45 ` Tejun Heo
2012-08-02 10:00 ` Sasha Levin
2012-08-02 10:32 ` Josh Triplett
2012-08-02 11:23 ` Sasha Levin
2012-08-02 13:04 ` Sasha Levin
2012-08-02 16:15 ` Josh Triplett
2012-08-02 16:48 ` Sasha Levin
2012-08-02 17:44 ` Josh Triplett
2012-08-02 17:54 ` Sasha Levin
2012-08-02 20:41 ` Josh Triplett
2012-08-02 21:47 ` Sasha Levin
2012-08-03 17:59 ` Josh Triplett
2012-08-02 16:03 ` Eric W. Biederman
2012-08-02 16:34 ` Sasha Levin
2012-08-02 16:40 ` Eric W. Biederman
2012-08-02 17:32 ` Linus Torvalds [this message]
2012-08-02 17:48 ` Eric Dumazet
2012-08-02 17:59 ` Josh Triplett
2012-08-02 18:08 ` Linus Torvalds
2012-08-02 20:25 ` Josh Triplett
2012-08-02 20:32 ` Linus Torvalds
2012-08-02 21:21 ` Josh Triplett
2012-08-02 21:50 ` Linus Torvalds
2012-08-02 9:35 ` Josh Triplett
2012-07-31 18:05 ` [RFC 2/4] user_ns: use new hashtable implementation Sasha Levin
2012-07-31 18:05 ` [RFC 3/4] mm,ksm: " Sasha Levin
2012-07-31 18:05 ` [RFC 4/4] workqueue: " 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=CA+55aFw_dwO5ZOuaz9eDxgnTZFDGVZKSLUTm5Fn99faALxxJRQ@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=josh@joshtriplett.org \
--cc=levinsasha928@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=paul.gortmaker@windriver.com \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox