public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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: Tue, 13 Jan 2004 00:32:24 +1100	[thread overview]
Message-ID: <20040112133224.GA7287@krispykreme> (raw)
In-Reply-To: <B05667366EE6204181EABE9C1B1C0EB5802444@scsmsx401.sc.intel.com>


> We don't have any data to justify any size change for x86, that was the
> main reason we limit the size by page order.

Well x86 isnt very interesting here, its all the 64bit archs that will
end up with TBs of memory in the future.

> If I read them correctly, most of the distribution is in the first 2
> buckets, so it doesn't matter whether you have 100 buckets or 1 million
> buckets, only first 2 are being hammered hard.  So are we wasting memory
> on the buckets that are not being used?

But look at the horrid worst case there. My point is limiting the hash
without any data is not a good idea. In 2.4 we raised MAX_ORDER on ppc64
because we spent so much time walking pagecache chains, id hate to see
us limit the icache and dcache hash in 2.6 and end up with a similar
problem.

Why cant we do something like Andrews recent min_free_kbytes patch and
make the rate of change non linear. Just slow the increase down as we
get bigger. I agree a 2GB hashtable is pretty ludicrous, but a 4MB one
on a 512GB machine (which we sell at the moment) could be too :)

Anton

  reply	other threads:[~2004-01-12 13:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-09 19:05 Limit hash table size Chen, Kenneth W
2004-01-12 13:32 ` Anton Blanchard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-02-18  0:45 Chen, Kenneth W
2004-02-18  0:16 Chen, Kenneth W
2004-02-17 22:24 Chen, Kenneth W
2004-02-17 23:24 ` Andrew Morton
2004-02-06  6:32 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  0:10 Chen, Kenneth W
2004-02-06  0:23 ` Andrew Morton
2004-02-09 23:12   ` Jes Sorensen
2004-01-14 22:31 Chen, Kenneth W
2004-01-18 14:25 ` Anton Blanchard
2004-01-14 22:29 Chen, Kenneth W
2004-01-12 16:50 Manfred Spraul
2004-01-08 23:12 Chen, Kenneth W
2004-01-09  9:25 ` Andrew Morton
2004-01-09 14:25 ` Anton Blanchard
2004-02-05 23:58 ` Andrew Morton

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=20040112133224.GA7287@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox