From: Anton Blanchard <anton@samba.org>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Limit hash table size
Date: Fri, 09 Jan 2004 14:25:45 +0000 [thread overview]
Message-ID: <20040109142544.GA23038@krispykreme> (raw)
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB5802441@scsmsx401.sc.intel.com>
Hi,
> Last time I checked, the tcp ehash table is taking a whooping (insane!)
> 2GB on one of our large machine. dentry and inode hash tables also take
> considerable amount of memory.
>
> This patch just enforces all the hash tables to have a max order of 10,
> which limits them down to 16MB each on ia64. People can clean up other
> part of table size calculation. But minimally, this patch doesn't
> change any hash sizes already in use on x86.
By limiting it by order you are crippling ppc64 compared to ia64 :)
Perhaps we should limit it by size instead.
Have you done any analysis of hash depths of large memory machines? We
had some extremely deep pagecache hashchains in 2.4 on a 64GB machine.
While the radix tree should fix that, whos to say we cant get into a
similar situation with the dcache?
Check out how deep some of the inode hash chains are here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.0/0105.html
That was on a 64GB box from memory. Switch to the current high end,
say 512GB and those chains could become a real dogs breakfast,
especially if we limit the hashtable to 4MB.
Anton
WARNING: multiple messages have this Message-ID (diff)
From: Anton Blanchard <anton@samba.org>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: Limit hash table size
Date: Sat, 10 Jan 2004 01:25:45 +1100 [thread overview]
Message-ID: <20040109142544.GA23038@krispykreme> (raw)
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB5802441@scsmsx401.sc.intel.com>
Hi,
> Last time I checked, the tcp ehash table is taking a whooping (insane!)
> 2GB on one of our large machine. dentry and inode hash tables also take
> considerable amount of memory.
>
> This patch just enforces all the hash tables to have a max order of 10,
> which limits them down to 16MB each on ia64. People can clean up other
> part of table size calculation. But minimally, this patch doesn't
> change any hash sizes already in use on x86.
By limiting it by order you are crippling ppc64 compared to ia64 :)
Perhaps we should limit it by size instead.
Have you done any analysis of hash depths of large memory machines? We
had some extremely deep pagecache hashchains in 2.4 on a 64GB machine.
While the radix tree should fix that, whos to say we cant get into a
similar situation with the dcache?
Check out how deep some of the inode hash chains are here:
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.0/0105.html
That was on a 64GB box from memory. Switch to the current high end,
say 512GB and those chains could become a real dogs breakfast,
especially if we limit the hashtable to 4MB.
Anton
next prev parent reply other threads:[~2004-01-09 14:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-08 23:12 Limit hash table size Chen, Kenneth W
2004-01-08 23:12 ` Chen, Kenneth W
2004-01-09 9:25 ` Andrew Morton
2004-01-09 9:25 ` Andrew Morton
2004-01-09 14:25 ` Anton Blanchard [this message]
2004-01-09 14:25 ` Anton Blanchard
2004-01-09 19:05 ` Chen, Kenneth W
2004-01-09 19:05 ` Chen, Kenneth W
2004-01-12 13:32 ` Anton Blanchard
2004-01-12 13:32 ` Anton Blanchard
2004-01-14 22:29 ` Chen, Kenneth W
2004-01-14 22:29 ` Chen, Kenneth W
2004-01-14 22:31 ` Chen, Kenneth W
2004-01-14 22:31 ` Chen, Kenneth W
2004-01-18 14:25 ` Anton Blanchard
2004-01-18 14:25 ` Anton Blanchard
2004-02-05 23:58 ` Andrew Morton
2004-02-05 23:58 ` Andrew Morton
2004-02-06 0:10 ` Chen, Kenneth W
2004-02-06 0:10 ` Chen, Kenneth W
2004-02-06 0:23 ` Andrew Morton
2004-02-06 0:23 ` Andrew Morton
2004-02-09 23:12 ` Jes Sorensen
2004-02-09 23:12 ` Jes Sorensen
2004-02-17 22:24 ` Chen, Kenneth W
2004-02-17 22:24 ` Chen, Kenneth W
2004-02-17 23:24 ` Andrew Morton
2004-02-17 23:24 ` Andrew Morton
2004-02-18 0:16 ` Chen, Kenneth W
2004-02-18 0:16 ` Chen, Kenneth W
2004-02-18 0:45 ` Chen, Kenneth W
2004-02-18 0:45 ` Chen, Kenneth W
-- strict thread matches above, loose matches on Subject: below --
2004-01-12 16:50 Manfred Spraul
[not found] <B05667366EE6204181EABE9C1B1C0EB5802441@scsmsx401.sc.intel.com.suse.lists.linux.kernel>
[not found] ` <20040205155813.726041bd.akpm@osdl.org.suse.lists.linux.kernel>
2004-02-06 1:54 ` Andi Kleen
2004-02-05 2:38 ` Steve Lord
2004-02-06 3:12 ` Andrew Morton
2004-02-05 4:06 ` Steve Lord
2004-02-06 4:39 ` Andi Kleen
2004-02-06 4:59 ` Andrew Morton
2004-02-06 5:34 ` Maneesh Soni
2004-02-06 3:19 ` Andi Kleen
2004-02-06 3:23 ` Nick Piggin
2004-02-06 3:34 ` Andrew Morton
2004-02-06 3:38 ` Nick Piggin
2004-02-18 12:41 ` Pavel Machek
2004-02-06 3:09 ` Andrew Morton
2004-02-06 3:18 ` Andi Kleen
2004-02-06 3:30 ` Andrew Morton
2004-02-06 4:45 ` Martin J. Bligh
2004-02-06 6:22 ` Matt Mackall
2004-02-06 20:20 ` Taneli Vähäkangas
2004-02-06 20:27 ` Andrew Morton
2004-02-06 21:46 ` Taneli Vähäkangas
2004-02-06 6:32 Manfred Spraul
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=20040109142544.GA23038@krispykreme \
--to=anton@samba.org \
--cc=akpm@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.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 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.