All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Pasha Tatashin <pasha.tatashin@oracle.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-mm@kvack.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 1/3] sparc64: NG4 memset 32 bits overflow
Date: Thu, 02 Mar 2017 00:12:28 +0000	[thread overview]
Message-ID: <20170302001228.GL16328@bombadil.infradead.org> (raw)
In-Reply-To: <1e7db21b-808d-1f47-e78c-7d55c543ae39@oracle.com>

On Wed, Mar 01, 2017 at 04:20:28PM -0500, Pasha Tatashin wrote:
> Hi Andi,
> 
> After thinking some more about this issue, I figured that I would not want
> to set default maximums.
> 
> Currently, the defaults are scaled with system memory size, which seems like
> the right thing to do to me. They are set to size hash tables one entry per
> page and, if a scale argument is provided, scale them down to 1/2, 1/4, 1/8
> entry per page etc.

I disagree that it's the right thing to do.  You want your dentry cache
to scale with the number of dentries in use.  Scaling with memory size
is a reasonable approximation for smaller memory sizes, but allocating
8GB of *hash table entries* for dentries is plainly ridiculous, no matter
how much memory you have.  You won't have half a billion dentries active
in most uses of such a large machine.

WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Pasha Tatashin <pasha.tatashin@oracle.com>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-mm@kvack.org, sparclinux@vger.kernel.org
Subject: Re: [PATCH v2 1/3] sparc64: NG4 memset 32 bits overflow
Date: Wed, 1 Mar 2017 16:12:28 -0800	[thread overview]
Message-ID: <20170302001228.GL16328@bombadil.infradead.org> (raw)
In-Reply-To: <1e7db21b-808d-1f47-e78c-7d55c543ae39@oracle.com>

On Wed, Mar 01, 2017 at 04:20:28PM -0500, Pasha Tatashin wrote:
> Hi Andi,
> 
> After thinking some more about this issue, I figured that I would not want
> to set default maximums.
> 
> Currently, the defaults are scaled with system memory size, which seems like
> the right thing to do to me. They are set to size hash tables one entry per
> page and, if a scale argument is provided, scale them down to 1/2, 1/4, 1/8
> entry per page etc.

I disagree that it's the right thing to do.  You want your dentry cache
to scale with the number of dentries in use.  Scaling with memory size
is a reasonable approximation for smaller memory sizes, but allocating
8GB of *hash table entries* for dentries is plainly ridiculous, no matter
how much memory you have.  You won't have half a billion dentries active
in most uses of such a large machine.

--
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>

  parent reply	other threads:[~2017-03-02  0:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-01  0:14 [PATCH v2 0/3] Zeroing hash tables in allocator Pavel Tatashin
2017-03-01  0:14 ` Pavel Tatashin
2017-03-01  0:14 ` [PATCH v2 1/3] sparc64: NG4 memset 32 bits overflow Pavel Tatashin
2017-03-01  0:14   ` Pavel Tatashin
2017-03-01  0:24   ` Andi Kleen
2017-03-01  0:24     ` Andi Kleen
2017-03-01 14:51     ` Pasha Tatashin
2017-03-01 14:51       ` Pasha Tatashin
2017-03-01 15:19       ` Andi Kleen
2017-03-01 15:19         ` Andi Kleen
2017-03-01 16:34         ` Pasha Tatashin
2017-03-01 16:34           ` Pasha Tatashin
2017-03-01 17:31           ` Andi Kleen
2017-03-01 17:31             ` Andi Kleen
2017-03-01 21:20             ` Pasha Tatashin
2017-03-01 21:20               ` Pasha Tatashin
2017-03-01 23:10               ` Andi Kleen
2017-03-01 23:10                 ` Andi Kleen
2017-03-02 19:15                 ` Pasha Tatashin
2017-03-02 19:15                   ` Pasha Tatashin
2017-03-02  0:12               ` Matthew Wilcox [this message]
2017-03-02  0:12                 ` Matthew Wilcox
2017-03-01  0:14 ` [PATCH v2 2/3] mm: Zeroing hash tables in allocator Pavel Tatashin
2017-03-01  0:14   ` Pavel Tatashin
2017-03-01  0:14 ` [PATCH v2 3/3] mm: Updated callers to use HASH_ZERO flag Pavel Tatashin
2017-03-01  0:14   ` Pavel Tatashin

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=20170302001228.GL16328@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@oracle.com \
    --cc=sparclinux@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.