From: Sharath Kumar Bhat <sharath.k.bhat@linux.intel.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Sharath Kumar Bhat <sharath.k.bhat@linux.intel.com>,
linux-mm@kvack.org, akpm@linux-foundation.org
Subject: Re: [PATCH] mm: fix movable_node kernel command-line
Date: Mon, 23 Oct 2017 10:35:44 -0700 [thread overview]
Message-ID: <20171023173544.GA12198@linux.intel.com> (raw)
In-Reply-To: <20171023172008.kr6dzpe63nfpgps7@dhcp22.suse.cz>
On Mon, Oct 23, 2017 at 07:20:08PM +0200, Michal Hocko wrote:
> On Mon 23-10-17 10:14:35, Sharath Kumar Bhat wrote:
> [...]
> > This lets admin to configure the kernel to have movable memory > size of
> > hotpluggable memories and at the same time hotpluggable nodes have only
> > movable memory.
>
> Put aside that I believe that having too much of movable memory is
> dangerous and people are not very prepared for that fact, what is the
> specific usecase. Allowing users something is nice but as I've said the
> interface is ugly already and putting more on top is not very desirable.
>
> > This is useful because it lets user to have more movable
> > memory in the system that can be offlined/onlined. When the same hardware
> > is shared between two OS's then this helps to dynamically provision the
> > physical memory between them by offlining/onlining as and when the
> > application/user need changes.
>
> just use hotplugable memory for that purpose. The latest memory hotplug
> code allows you to online memory into a kernel or movable zone as per
> admin policy without the previously hardcoded zone ordering. So I really
> fail to see why to mock with the command line parameter at all.
Yes, but it won't let us offline the memory blocks if they are already
in use by kernel allocations. This is more likely over a long period of
uptime. The command-line ensures that the memory blocks are movable all
the time as reserved by the admin from the boot.
--
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>
next prev parent reply other threads:[~2017-10-23 17:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-20 23:32 Sharath Kumar Bhat
2017-10-23 12:52 ` Michal Hocko
2017-10-23 16:03 ` Sharath Kumar Bhat
2017-10-23 16:15 ` Michal Hocko
2017-10-23 17:14 ` Sharath Kumar Bhat
2017-10-23 17:20 ` Michal Hocko
2017-10-23 17:35 ` Sharath Kumar Bhat [this message]
2017-10-23 17:49 ` Michal Hocko
2017-10-23 18:48 ` Sharath Kumar Bhat
2017-10-23 19:04 ` Michal Hocko
2017-10-23 19:25 ` Sharath Kumar Bhat
2017-10-23 19:35 ` Michal Hocko
2017-10-23 19:56 ` Sharath Kumar Bhat
2017-10-23 21:52 ` Dave Hansen
2017-10-24 1:06 ` Sharath Kumar Bhat
2017-10-24 7:19 ` Michal Hocko
2017-10-25 0:53 ` Sharath Kumar Bhat
2017-10-25 6:38 ` Michal Hocko
2017-10-25 22:01 ` Sharath Kumar Bhat
2017-10-26 7:36 ` Michal Hocko
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=20171023173544.GA12198@linux.intel.com \
--to=sharath.k.bhat@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@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