All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: Oscar Salvador <osalvador@techadventures.net>
Cc: Michal Hocko <mhocko@kernel.org>,
	akpm@linux-foundation.org, dan.j.williams@intel.com,
	Pavel.Tatashin@microsoft.com, david@redhat.com,
	yasu.isimatu@gmail.com, logang@deltatee.com,
	dave.jiang@intel.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Oscar Salvador <osalvador@suse.de>
Subject: Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages
Date: Thu, 16 Aug 2018 13:32:01 -0400	[thread overview]
Message-ID: <20180816173201.GC28097@redhat.com> (raw)
In-Reply-To: <20180816145849.GA17638@techadventures.net>

On Thu, Aug 16, 2018 at 04:58:49PM +0200, Oscar Salvador wrote:
> On Thu, Aug 09, 2018 at 12:58:21PM -0400, Jerome Glisse wrote:
> > I agree, i never thought about that before. Looking at existing resource
> > management i think the simplest solution would be to use a refcount on the
> > resources instead of the IORESOURCE_BUSY flags.
> > 
> > So when you release resource as part of hotremove you would only dec the
> > refcount and a resource is not busy only when refcount is zero.
> > 
> > Just the idea i had in mind. Right now i am working on other thing, Oscar
> > is this something you would like to work on ? Feel free to come up with
> > something better than my first idea :)
> 
> So, I thought a bit about this.
> First I talked a bit with Jerome about the refcount idea.
> The problem with reconverting this to refcount is that it is too intrusive,
> and I think it is not really needed.
> 
> I then thought about defining a new flag, something like
> 
> #define IORESOURCE_NO_HOTREMOVE	xxx
> 
> but we ran out of bits for the flag field.
> 
> I then thought about doing something like:
> 
> struct resource {
>         resource_size_t start;
>         resource_size_t end;
>         const char *name;
>         unsigned long flags;
>         unsigned long desc;
>         struct resource *parent, *sibling, *child;
> #ifdef CONFIG_MEMORY_HOTREMOVE
>         bool device_managed;
> #endif
> };
> 
> but it is just too awful, not needed, and bytes consuming.

Agree the above is ugly.

> 
> The only idea I had left is:
> 
> register_memory_resource(), which defines a new resource for the added memory-chunk
> is only called from add_memory().
> This function is only being hit when we add memory-chunks.
> 
> HMM/devm gets the resources their own way, calling devm_request_mem_region().
> 
> So resources that are requested from HMM/devm, have the following flags:
> 
>  (IORESOURCE_MEM|IORESOURCE_BUSY)
> 
> while resources that are requested via mem-hotplug have:
> 
>  (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY)
> 
> IORESOURCE_SYSTEM_RAM = (IORESOURCE_MEM|IORESOURCE_SYSRAM)
> 
> 
> release_mem_region_adjustable() is only being called from hot-remove path, so
> unless I am mistaken, all resources hitting that path should match IORESOURCE_SYSTEM_RAM.
> 
> That leaves me with the idea that we could check for the resource->flags to contain IORESOURCE_SYSRAM,
> as I think it is only being set for memory-chunks that are added via memory-hot-add path.
> 
> In case it is not, we know that that resource belongs to HMM/devm, so we can back off since
> they take care of releasing the resource via devm_release_mem_region.
> 
> I am working on a RFC v2 containing this, but, Jerome, could you confirm above assumption, please?

I think you nail it. I am not 100% sure about devm as i have not
followed closely how persistent memory can be reported by ACPI. But
i am pretty sure it should never end up as SYSRAM.

Thank you for scratching your head on this :)

Cheers,
Jerome

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: Oscar Salvador <osalvador@techadventures.net>
Cc: Michal Hocko <mhocko@kernel.org>,
	akpm@linux-foundation.org, dan.j.williams@intel.com,
	Pavel.Tatashin@microsoft.com, david@redhat.com,
	yasu.isimatu@gmail.com, logang@deltatee.com,
	dave.jiang@intel.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Oscar Salvador <osalvador@suse.de>
Subject: Re: [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages
Date: Thu, 16 Aug 2018 13:32:01 -0400	[thread overview]
Message-ID: <20180816173201.GC28097@redhat.com> (raw)
In-Reply-To: <20180816145849.GA17638@techadventures.net>

On Thu, Aug 16, 2018 at 04:58:49PM +0200, Oscar Salvador wrote:
> On Thu, Aug 09, 2018 at 12:58:21PM -0400, Jerome Glisse wrote:
> > I agree, i never thought about that before. Looking at existing resource
> > management i think the simplest solution would be to use a refcount on the
> > resources instead of the IORESOURCE_BUSY flags.
> > 
> > So when you release resource as part of hotremove you would only dec the
> > refcount and a resource is not busy only when refcount is zero.
> > 
> > Just the idea i had in mind. Right now i am working on other thing, Oscar
> > is this something you would like to work on ? Feel free to come up with
> > something better than my first idea :)
> 
> So, I thought a bit about this.
> First I talked a bit with Jerome about the refcount idea.
> The problem with reconverting this to refcount is that it is too intrusive,
> and I think it is not really needed.
> 
> I then thought about defining a new flag, something like
> 
> #define IORESOURCE_NO_HOTREMOVE	xxx
> 
> but we ran out of bits for the flag field.
> 
> I then thought about doing something like:
> 
> struct resource {
>         resource_size_t start;
>         resource_size_t end;
>         const char *name;
>         unsigned long flags;
>         unsigned long desc;
>         struct resource *parent, *sibling, *child;
> #ifdef CONFIG_MEMORY_HOTREMOVE
>         bool device_managed;
> #endif
> };
> 
> but it is just too awful, not needed, and bytes consuming.

Agree the above is ugly.

> 
> The only idea I had left is:
> 
> register_memory_resource(), which defines a new resource for the added memory-chunk
> is only called from add_memory().
> This function is only being hit when we add memory-chunks.
> 
> HMM/devm gets the resources their own way, calling devm_request_mem_region().
> 
> So resources that are requested from HMM/devm, have the following flags:
> 
>  (IORESOURCE_MEM|IORESOURCE_BUSY)
> 
> while resources that are requested via mem-hotplug have:
> 
>  (IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY)
> 
> IORESOURCE_SYSTEM_RAM = (IORESOURCE_MEM|IORESOURCE_SYSRAM)
> 
> 
> release_mem_region_adjustable() is only being called from hot-remove path, so
> unless I am mistaken, all resources hitting that path should match IORESOURCE_SYSTEM_RAM.
> 
> That leaves me with the idea that we could check for the resource->flags to contain IORESOURCE_SYSRAM,
> as I think it is only being set for memory-chunks that are added via memory-hot-add path.
> 
> In case it is not, we know that that resource belongs to HMM/devm, so we can back off since
> they take care of releasing the resource via devm_release_mem_region.
> 
> I am working on a RFC v2 containing this, but, Jerome, could you confirm above assumption, please?

I think you nail it. I am not 100% sure about devm as i have not
followed closely how persistent memory can be reported by ACPI. But
i am pretty sure it should never end up as SYSRAM.

Thank you for scratching your head on this :)

Cheers,
Jérôme

  reply	other threads:[~2018-08-16 17:32 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 13:37 [RFC PATCH 0/3] Do not touch pages in remove_memory path osalvador
2018-08-07 13:37 ` [RFC PATCH 1/3] mm/memory_hotplug: Add nid parameter to arch_remove_memory osalvador
2018-08-07 13:37 ` [RFC PATCH 2/3] mm/memory_hotplug: Create __shrink_pages and move it to offline_pages osalvador
2018-08-07 13:52   ` Jerome Glisse
2018-08-07 13:52     ` Jerome Glisse
2018-08-07 14:54     ` David Hildenbrand
2018-08-07 14:54       ` David Hildenbrand
2018-08-07 15:19       ` Jerome Glisse
2018-08-07 15:19         ` Jerome Glisse
2018-08-07 15:28         ` David Hildenbrand
2018-08-07 15:28           ` David Hildenbrand
2018-08-07 20:48       ` Oscar Salvador
2018-08-07 22:13         ` Jerome Glisse
2018-08-07 22:13           ` Jerome Glisse
2018-08-08  7:38           ` Oscar Salvador
2018-08-08  7:45             ` David Hildenbrand
2018-08-08  7:56               ` Oscar Salvador
2018-08-08  8:08                 ` David Hildenbrand
2018-08-08 13:42                   ` Oscar Salvador
2018-08-08 17:55                     ` Jerome Glisse
2018-08-08 17:55                       ` Jerome Glisse
2018-08-08 21:29                       ` Oscar Salvador
2018-08-09  7:50                         ` Oscar Salvador
2018-08-09  7:52                           ` Oscar Salvador
2018-08-08  7:51             ` David Hildenbrand
2018-08-08  8:00               ` Oscar Salvador
2018-08-07 14:59     ` Michal Hocko
2018-08-07 15:18       ` Jerome Glisse
2018-08-07 15:18         ` Jerome Glisse
2018-08-08  6:47         ` Michal Hocko
2018-08-08 16:58           ` Jerome Glisse
2018-08-08 16:58             ` Jerome Glisse
2018-08-08 21:28             ` Oscar Salvador
2018-08-09  8:24             ` Michal Hocko
2018-08-09 14:27               ` Jerome Glisse
2018-08-09 14:27                 ` Jerome Glisse
2018-08-09 15:09                 ` Michal Hocko
2018-08-09 16:58                   ` Jerome Glisse
2018-08-09 16:58                     ` Jerome Glisse
2018-08-09 20:50                     ` Oscar Salvador
2018-08-16 14:58                     ` Oscar Salvador
2018-08-16 17:32                       ` Jerome Glisse [this message]
2018-08-16 17:32                         ` Jerome Glisse
2018-08-08  9:45         ` Oscar Salvador
2018-08-08  9:45           ` Oscar Salvador
2018-08-08 17:33           ` Jerome Glisse
2018-08-08 17:33             ` Jerome Glisse
2018-08-07 13:37 ` [RFC PATCH 3/3] mm/memory_hotplug: Refactor shrink_zone/pgdat_span osalvador
2018-08-07 14:16 ` [RFC PATCH 0/3] Do not touch pages in remove_memory path David Hildenbrand
2018-08-07 14:19   ` Oscar Salvador
2018-08-07 14:20     ` David Hildenbrand
2018-08-07 14:28       ` Oscar Salvador
2018-08-07 14:41         ` David Hildenbrand
2018-08-07 14:52           ` Oscar Salvador
2018-08-15 14:05 ` Pavel Tatashin
2018-08-15 14:32   ` Oscar Salvador

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=20180816173201.GC28097@redhat.com \
    --to=jglisse@redhat.com \
    --cc=Pavel.Tatashin@microsoft.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=osalvador@techadventures.net \
    --cc=yasu.isimatu@gmail.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 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.