linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Michal Suchánek" <msuchanek@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: "Kate Stewart" <kstewart@linuxfoundation.org>,
	"Rich Felker" <dalias@libc.org>,
	linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Heiko Carstens" <heiko.carstens@de.ibm.com>,
	linux-mm@kvack.org, "Michal Hocko" <mhocko@suse.com>,
	"Paul Mackerras" <paulus@samba.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"Stephen Rothwell" <sfr@canb.auug.org.au>,
	"Rashmica Gupta" <rashmica.g@gmail.com>
Subject: Re: [PATCH RFC] mm/memory_hotplug: Introduce memory block types
Date: Mon, 26 Nov 2018 15:20:15 +0100	[thread overview]
Message-ID: <20181126152015.7464c786@naga> (raw)
In-Reply-To: <b64a0e1e-6aaa-66a9-2fb7-12daa6383ce1@redhat.com>

On Mon, 26 Nov 2018 14:33:29 +0100
David Hildenbrand <david@redhat.com> wrote:

> On 26.11.18 13:30, David Hildenbrand wrote:
> > On 23.11.18 19:06, Michal Suchánek wrote:  

> >>
> >> If we are going to fake the driver information we may as well add the
> >> type attribute and be done with it.
> >>
> >> I think the problem with the patch was more with the semantic than the
> >> attribute itself.
> >>
> >> What is normal, paravirtualized, and standby memory?
> >>
> >> I can understand DIMM device, baloon device, or whatever mechanism for
> >> adding memory you might have.
> >>
> >> I can understand "memory designated as standby by the cluster
> >> administrator".
> >>
> >> However, DIMM vs baloon is orthogonal to standby and should not be
> >> conflated into one property.
> >>
> >> paravirtualized means nothing at all in relationship to memory type and
> >> the desired online policy to me.  
> > 
> > Right, so with whatever we come up, it should allow to make a decision
> > in user space about
> > - if memory is to be onlined automatically  
> 
> And I will think about if we really should model standby memory. Maybe
> it is really better to have in user space something like (as Dan noted)

If it is possible to designate the memory as standby or online in the
s390 admin interface and the kernel does have access to this
information it makes sense to forward it to userspace (as separate
s390-specific property). If not then you need to make some kind of
assumption like below and the user can tune the script according to
their usecase.

> 
> if (isS390x() && type == "dimm") {
> 	/* don't online, on s390x system DIMMs are standby memory */
> }

Thanks

Michal

  reply	other threads:[~2018-11-26 14:20 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28 15:03 David Hildenbrand
2018-09-28 17:02 ` Dave Hansen
2018-10-01  9:13   ` David Hildenbrand
2018-10-01 16:24     ` Dave Hansen
2018-10-04  7:48       ` David Hildenbrand
2018-10-01  8:40 ` Michal Hocko
2018-10-01  9:34   ` David Hildenbrand
2018-10-02 13:47     ` Michal Hocko
2018-10-02 15:25       ` David Hildenbrand
2018-10-03 13:38         ` Vitaly Kuznetsov
2018-10-03 13:44           ` Michal Hocko
2018-10-03 13:52             ` Vitaly Kuznetsov
2018-10-03 14:07               ` Dave Hansen
2018-10-03 14:34                 ` Vitaly Kuznetsov
2018-10-03 17:14                   ` David Hildenbrand
2018-10-04  6:19                     ` Michal Hocko
2018-10-04  8:13                       ` David Hildenbrand
2018-10-04 15:28                         ` Michal Suchánek
2018-10-04 15:45                           ` David Hildenbrand
2018-10-04 17:50                             ` Michal Suchánek
2018-10-05  7:37                               ` David Hildenbrand
2018-10-03 14:24               ` Michal Hocko
2018-10-03 17:06                 ` David Hildenbrand
2018-10-04  8:12                 ` David Hildenbrand
2018-10-03 13:54         ` Michal Hocko
2018-10-03 17:00           ` David Hildenbrand
2018-10-04  6:28             ` Michal Hocko
2018-10-04  7:40               ` David Hildenbrand
2018-11-23 11:13 ` David Hildenbrand
2018-11-23 18:06   ` Michal Suchánek
2018-11-26 12:30     ` David Hildenbrand
2018-11-26 13:33       ` David Hildenbrand
2018-11-26 14:20         ` Michal Suchánek [this message]
2018-11-26 15:59           ` David Hildenbrand
2018-11-27 16:32             ` Michal Suchánek
2018-11-27 16:47               ` David Hildenbrand

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=20181126152015.7464c786@naga \
    --to=msuchanek@suse.de \
    --cc=dalias@libc.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hpa@zytor.com \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rashmica.g@gmail.com \
    --cc=sfr@canb.auug.org.au \
    /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