From: Shuah Khan <shuah@kernel.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Will Deacon <will.deacon@arm.com>,
catalin.marinas@arm.com, sudeep.holla@arm.com,
ganapatrao.kulkarni@cavium.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Shuah Khan <shuah@kernel.org>
Subject: Re: [PATCH] arm64: add NUMA emulation support
Date: Thu, 6 Sep 2018 15:53:34 -0600 [thread overview]
Message-ID: <c1b58f13-6190-20e9-7e4f-b8bc2b9d5f80@kernel.org> (raw)
In-Reply-To: <20180905064252.GW14951@dhcp22.suse.cz>
On 09/05/2018 12:42 AM, Michal Hocko wrote:
> On Tue 04-09-18 15:59:34, Shuah Khan wrote:
> [...]
>> This will support the following workload requirements:
>>
>> - reserving one or more NUMA memory nodes for class of critical tasks that require
>> guaranteed memory availability.
>> - isolate memory blocks with a guaranteed exclusive access.
>
> How do you enforce kernel doesn't allocate from those reserved nodes?
> They will be in a fallback zonelists so once the memory gets used on all
> other ones then the kernel happily spills over to your reserved node.
I should have clarified the "isolate memory blocks with a guaranteed exclusive
access." scope.
Kernel does satisfy GFP_ATOMIC at the expense of cpuset exclusive/hardwall policies
to not stress the kernel.
It is not the intent to make sure kernel doesn't allocate from these reserved
nodes. The intent is to work within the constraints of cpuset mem.exclusive and
cpuset mem.hardwall policies.
>
>> NUMA emulation to split the flat machine into "x" number of nodes, combined with
>> cpuset cgroup with the following example configuration will make it possible to
>> support the above workloads on non-NUMA platforms.
>>
>> numa=fake=4
>>
>> cpuset.mems=2
>> cpuset.cpus=2
>> cpuset.mem_exclusive=1 (enabling exclusive use of the memory nodes by a CPU set)
>> cpuset.mem_hardwall=1 (separate the memory nodes that are allocated to different cgroups)
>
> This will only enforce userspace to follow and I strongly suspect that
> tasks in the root cgroup will be allowed to allocate as well.
>
A few critical allocations could be satisfied and root cgroup prevails. It is not the
intent to have exclusivity at the expense of the kernel.
This feature will allow a way to configure cpusets on non-NUMA for workloads that can
benefit from the reservation and isolation that is available within the constraints of
exclusive cpuset policies.
thanks,
-- Shuah
next prev parent reply other threads:[~2018-09-06 21:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-24 23:05 Shuah Khan (Samsung OSG)
2018-08-28 17:40 ` Will Deacon
2018-08-28 18:09 ` Shuah Khan
2018-08-29 11:08 ` Michal Hocko
2018-09-04 21:59 ` Shuah Khan
2018-09-05 6:42 ` Michal Hocko
2018-09-06 21:53 ` Shuah Khan [this message]
2018-09-07 8:34 ` Michal Hocko
2018-09-07 22:30 ` Shuah Khan
2018-09-10 13:48 ` Michal Hocko
2018-09-11 2:02 ` Shuah Khan
2018-09-11 9:11 ` Michal Hocko
2018-09-11 15:27 ` Shuah Khan
2018-09-11 16:50 ` Will Deacon
2018-09-11 19:53 ` Shuah Khan
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=c1b58f13-6190-20e9-7e4f-b8bc2b9d5f80@kernel.org \
--to=shuah@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=ganapatrao.kulkarni@cavium.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
/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
all inboxes | Powered by JetHome®