From: Andi Kleen <andi@firstfloor.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andi Kleen <andi@firstfloor.org>,
David Miller <davem@davemloft.net>,
ebiederm@xmission.com, bcrl@kvack.org,
linux-kernel@vger.kernel.org, torvalds@linux-foundation.org
Subject: Re: regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces
Date: Mon, 7 Jan 2008 23:57:41 +0100 [thread overview]
Message-ID: <20080107225740.GA14758@one.firstfloor.org> (raw)
In-Reply-To: <20080107213054.23270044@lxorguk.ukuu.org.uk>
On Mon, Jan 07, 2008 at 09:30:54PM +0000, Alan Cox wrote:
> > I think that would be a better option than to complicate sysctl.c
> > for this uncommon case.
>
> What is so complicated about hashing the entries if you are checking for
One thing I'm worrying about is memory bloat (yes I know that's not
popular but someone has to do it ;-)
You would need a hash table for each table. To handle 100k entries
you would need a larger hash tables with at least a few hundred entries.
And that for each subdirectory.
% find /proc/sys -type d | wc -l
64
Assuming e.g. a 128 byte entry hash table (which is probably too small
for 100k entries) that would require 64 * 128 * 8 = 64k of memory.
Not gigantic, but lots of small fry bloat also adds up. Now if you
chose an actually realistic hash table size it gets even bigger.
Most likely you would need to implement a tree or a resizeable hash table
to do this sanely and then you quickly go into complicated territory.
> duplicates when debugging. You can set the hash function to "0" and the
My understanding was that the code was always on; not only for debugging.
-Andi
prev parent reply other threads:[~2008-01-07 22:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-06 22:03 regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces Benjamin LaHaise
2008-01-07 6:57 ` Eric W. Biederman
2008-01-07 7:10 ` David Miller
2008-01-07 10:25 ` Eric W. Biederman
2008-01-08 1:47 ` Benjamin LaHaise
2008-01-07 20:45 ` Andi Kleen
2008-01-07 21:30 ` Alan Cox
2008-01-07 22:57 ` Andi Kleen [this message]
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=20080107225740.GA14758@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bcrl@kvack.org \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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