From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: <aleksey.makarov@auriga.com>, <james.hogan@imgtec.com>,
<paul.burton@imgtec.com>, <david.daney@cavium.com>,
<peterz@infradead.org>, <linux-mips@linux-mips.org>,
<linux-kernel@vger.kernel.org>, <davidlohr@hp.com>,
<kirill@shutemov.name>, <akpm@linux-foundation.org>,
<mingo@kernel.org>
Subject: Re: [PATCH v2] MIPS64: Support of at least 48 bits of SEGBITS
Date: Fri, 15 May 2015 15:39:54 -0700 [thread overview]
Message-ID: <555675BA.9000700@imgtec.com> (raw)
In-Reply-To: <20150515215320.GI2322@linux-mips.org>
On 05/15/2015 02:53 PM, Ralf Baechle wrote:
> On Thu, May 14, 2015 at 06:34:43PM -0700, Leonid Yegoshin wrote:
>
> The order 1 allocation for the PGD are concerning me a little. On a
> system under even moderate memory pressure that might become a bit of
> a reliability or performance issue.
>
> With 4kB pages we already need order 1 or even 2 allocations for the
> allocation of the stack and some folks have reported that to be an issue
> so we may have to start using the PUD for very large VA spaces.
>
> Ralf
I don't think it is an issue here - people, who wants to exercise 256
TERABAIT of memory PER PROCESS may even doesn't note that they have PGD
= 2 pages. It is definitely not for systems with 4GB physmemory.
I also recommend for low memory to look into CONFIG_COMPACTION, it may
be a great help for them here, look into mm/vmscan.c,
in_reclaim_compaction().
Besides that, I defined this feature for 16KB and 64KB pages only, not
for 4KB.
WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: aleksey.makarov@auriga.com, james.hogan@imgtec.com,
paul.burton@imgtec.com, david.daney@cavium.com,
peterz@infradead.org, linux-mips@linux-mips.org,
linux-kernel@vger.kernel.org, davidlohr@hp.com,
kirill@shutemov.name, akpm@linux-foundation.org,
mingo@kernel.org
Subject: Re: [PATCH v2] MIPS64: Support of at least 48 bits of SEGBITS
Date: Fri, 15 May 2015 15:39:54 -0700 [thread overview]
Message-ID: <555675BA.9000700@imgtec.com> (raw)
Message-ID: <20150515223954.RuiAdbVtuu9yZFg7RvnbGdAxiiz1Pl3RICKFKpQpX04@z> (raw)
In-Reply-To: <20150515215320.GI2322@linux-mips.org>
On 05/15/2015 02:53 PM, Ralf Baechle wrote:
> On Thu, May 14, 2015 at 06:34:43PM -0700, Leonid Yegoshin wrote:
>
> The order 1 allocation for the PGD are concerning me a little. On a
> system under even moderate memory pressure that might become a bit of
> a reliability or performance issue.
>
> With 4kB pages we already need order 1 or even 2 allocations for the
> allocation of the stack and some folks have reported that to be an issue
> so we may have to start using the PUD for very large VA spaces.
>
> Ralf
I don't think it is an issue here - people, who wants to exercise 256
TERABAIT of memory PER PROCESS may even doesn't note that they have PGD
= 2 pages. It is definitely not for systems with 4GB physmemory.
I also recommend for low memory to look into CONFIG_COMPACTION, it may
be a great help for them here, look into mm/vmscan.c,
in_reclaim_compaction().
Besides that, I defined this feature for 16KB and 64KB pages only, not
for 4KB.
next prev parent reply other threads:[~2015-05-15 22:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 1:34 [PATCH v2] MIPS64: Support of at least 48 bits of SEGBITS Leonid Yegoshin
2015-05-15 1:34 ` Leonid Yegoshin
2015-05-15 10:39 ` Sergei Shtylyov
2015-05-15 16:28 ` David Daney
2015-05-15 19:03 ` Leonid Yegoshin
2015-05-16 2:11 ` Maciej W. Rozycki
2015-05-15 20:49 ` David Daney
2015-05-15 21:01 ` Leonid Yegoshin
2015-05-15 21:01 ` Leonid Yegoshin
2015-05-15 21:53 ` Ralf Baechle
2015-05-15 22:39 ` Leonid Yegoshin [this message]
2015-05-15 22:39 ` Leonid Yegoshin
2015-05-16 2:42 ` Joshua Kinard
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=555675BA.9000700@imgtec.com \
--to=leonid.yegoshin@imgtec.com \
--cc=akpm@linux-foundation.org \
--cc=aleksey.makarov@auriga.com \
--cc=david.daney@cavium.com \
--cc=davidlohr@hp.com \
--cc=james.hogan@imgtec.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=mingo@kernel.org \
--cc=paul.burton@imgtec.com \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.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.