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

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.

So, in some cases the scale argument may be wrong, and dentry, inode, or 
some other client of alloc_large_system_hash() should be adjusted.

For example, I am pretty sure that scale value in most places should be 
changed from literal value (inode scale = 14, dentry scale = 13, etc to: 
(PAGE_SHIFT + value): inode scale would become (PAGE_SHIFT + 2), dentry 
scale would become (PAGE_SHIFT + 1), etc. This is because we want 1/4 
inodes and 1/2 dentries per every page in the system.
In alloc_large_system_hash() we have basically this:
nentries = nr_kernel_pages >> (scale - PAGE_SHIFT);

This is basically a bug, and would not change the theory, but I am sure 
that changing scales without at least some theoretical backup is not a 
good idea and would most likely lead to regressions, especially on some 
smaller configurations.

Therefore, in my opinion having one fast way to zero hash tables, as 
this patch tries to do, is a good thing. In the next patch revision I 
can go ahead and change scales to be (PAGE_SHIFT + val) from current 
literals.

Thank you,
Pasha

On 2017-03-01 12:31, Andi Kleen wrote:
> On Wed, Mar 01, 2017 at 11:34:10AM -0500, Pasha Tatashin wrote:
>> Hi Andi,
>>
>> Thank you for your comment, I am thinking to limit the default
>> maximum hash tables sizes to 512M.
>>
>> If it is bigger than 512M, we would still need my patch to improve
>
> Even 512MB seems too large. I wouldn't go larger than a few tens
> of MB, maybe 32MB.
>
> Also you would need to cover all the big hashes.
>
> The most critical ones are likely the network hash tables, these
> maybe be a bit larger (but certainly also not 0.5TB)
>
> -Andi
>


WARNING: multiple messages have this Message-ID (diff)
From: Pasha Tatashin <pasha.tatashin@oracle.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: 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:20:28 -0500	[thread overview]
Message-ID: <1e7db21b-808d-1f47-e78c-7d55c543ae39@oracle.com> (raw)
In-Reply-To: <20170301173136.GI26852@two.firstfloor.org>

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.

So, in some cases the scale argument may be wrong, and dentry, inode, or 
some other client of alloc_large_system_hash() should be adjusted.

For example, I am pretty sure that scale value in most places should be 
changed from literal value (inode scale = 14, dentry scale = 13, etc to: 
(PAGE_SHIFT + value): inode scale would become (PAGE_SHIFT + 2), dentry 
scale would become (PAGE_SHIFT + 1), etc. This is because we want 1/4 
inodes and 1/2 dentries per every page in the system.
In alloc_large_system_hash() we have basically this:
nentries = nr_kernel_pages >> (scale - PAGE_SHIFT);

This is basically a bug, and would not change the theory, but I am sure 
that changing scales without at least some theoretical backup is not a 
good idea and would most likely lead to regressions, especially on some 
smaller configurations.

Therefore, in my opinion having one fast way to zero hash tables, as 
this patch tries to do, is a good thing. In the next patch revision I 
can go ahead and change scales to be (PAGE_SHIFT + val) from current 
literals.

Thank you,
Pasha

On 2017-03-01 12:31, Andi Kleen wrote:
> On Wed, Mar 01, 2017 at 11:34:10AM -0500, Pasha Tatashin wrote:
>> Hi Andi,
>>
>> Thank you for your comment, I am thinking to limit the default
>> maximum hash tables sizes to 512M.
>>
>> If it is bigger than 512M, we would still need my patch to improve
>
> Even 512MB seems too large. I wouldn't go larger than a few tens
> of MB, maybe 32MB.
>
> Also you would need to cover all the big hashes.
>
> The most critical ones are likely the network hash tables, these
> maybe be a bit larger (but certainly also not 0.5TB)
>
> -Andi
>

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

  reply	other threads:[~2017-03-01 21:20 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 [this message]
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
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=1e7db21b-808d-1f47-e78c-7d55c543ae39@oracle.com \
    --to=pasha.tatashin@oracle.com \
    --cc=andi@firstfloor.org \
    --cc=linux-mm@kvack.org \
    --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.