From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-s390@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-sh@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Wei Yang <richardw.yang@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages()
Date: Wed, 05 Feb 2020 12:51:49 +0000 [thread overview]
Message-ID: <20200205125149.GS22482@gate.crashing.org> (raw)
In-Reply-To: <0e2f700c-b01b-8c16-99c2-2648967fc203@redhat.com>
On Tue, Feb 04, 2020 at 02:38:51PM +0100, David Hildenbrand wrote:
> On 04.02.20 14:13, Segher Boessenkool wrote:
> > On Tue, Feb 04, 2020 at 01:41:06PM +0100, David Hildenbrand wrote:
> >> It's a pattern commonly used in compilers and emulators to calculate the
> >> number of bytes to the next block/alignment. (we're missing a macro
> >> (like we have ALIGN_UP/IS_ALIGNED) for that - but it's hard to come up
> >> with a good name (e.g., SIZE_TO_NEXT_ALIGN) .
> > You can just write the easy to understand
> >
> > ... ALIGN_UP(x) - x ...
>
> you mean
>
> ALIGN_UP(x, PAGES_PER_SECTION) - x
>
> but ...
>
> > which is better *without* having a separate name. Does that not
> > generate good machine code for you?
>
> 1. There is no ALIGN_UP. "SECTION_ALIGN_UP(x) - x" would be possible
Erm, you started it ;-)
> 2. It would be wrong if x is already aligned.
>
> e.g., let's use 4096 for simplicity as we all know that value by heart
> (for both x and the block size).
>
> a) -(4096 | -4096) -> 4096
>
> b) #define ALIGN_UP(x, a) ((x + a - 1) & -(a))
>
> ALIGN_UP(4096, 4096) - 4096 -> 0
>
> Not as easy as it seems ...
If you always want to return a number >= 1, it it simply
ALIGN_UP(x + 1) - x
(and replace 1 by any other minimum size required). This *also* is
easy to read, without having to have any details (and quirks :-/ )
of those utility functions memorised.
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Hildenbrand <david@redhat.com>
Cc: Oscar Salvador <osalvador@suse.de>,
linux-s390@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-sh@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Wei Yang <richardw.yang@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages()
Date: Wed, 5 Feb 2020 06:51:49 -0600 [thread overview]
Message-ID: <20200205125149.GS22482@gate.crashing.org> (raw)
In-Reply-To: <0e2f700c-b01b-8c16-99c2-2648967fc203@redhat.com>
On Tue, Feb 04, 2020 at 02:38:51PM +0100, David Hildenbrand wrote:
> On 04.02.20 14:13, Segher Boessenkool wrote:
> > On Tue, Feb 04, 2020 at 01:41:06PM +0100, David Hildenbrand wrote:
> >> It's a pattern commonly used in compilers and emulators to calculate the
> >> number of bytes to the next block/alignment. (we're missing a macro
> >> (like we have ALIGN_UP/IS_ALIGNED) for that - but it's hard to come up
> >> with a good name (e.g., SIZE_TO_NEXT_ALIGN) .
> > You can just write the easy to understand
> >
> > ... ALIGN_UP(x) - x ...
>
> you mean
>
> ALIGN_UP(x, PAGES_PER_SECTION) - x
>
> but ...
>
> > which is better *without* having a separate name. Does that not
> > generate good machine code for you?
>
> 1. There is no ALIGN_UP. "SECTION_ALIGN_UP(x) - x" would be possible
Erm, you started it ;-)
> 2. It would be wrong if x is already aligned.
>
> e.g., let's use 4096 for simplicity as we all know that value by heart
> (for both x and the block size).
>
> a) -(4096 | -4096) -> 4096
>
> b) #define ALIGN_UP(x, a) ((x + a - 1) & -(a))
>
> ALIGN_UP(4096, 4096) - 4096 -> 0
>
> Not as easy as it seems ...
If you always want to return a number >= 1, it it simply
ALIGN_UP(x + 1) - x
(and replace 1 by any other minimum size required). This *also* is
easy to read, without having to have any details (and quirks :-/ )
of those utility functions memorised.
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-s390@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-sh@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Wei Yang <richardw.yang@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages()
Date: Wed, 5 Feb 2020 06:51:49 -0600 [thread overview]
Message-ID: <20200205125149.GS22482@gate.crashing.org> (raw)
In-Reply-To: <0e2f700c-b01b-8c16-99c2-2648967fc203@redhat.com>
On Tue, Feb 04, 2020 at 02:38:51PM +0100, David Hildenbrand wrote:
> On 04.02.20 14:13, Segher Boessenkool wrote:
> > On Tue, Feb 04, 2020 at 01:41:06PM +0100, David Hildenbrand wrote:
> >> It's a pattern commonly used in compilers and emulators to calculate the
> >> number of bytes to the next block/alignment. (we're missing a macro
> >> (like we have ALIGN_UP/IS_ALIGNED) for that - but it's hard to come up
> >> with a good name (e.g., SIZE_TO_NEXT_ALIGN) .
> > You can just write the easy to understand
> >
> > ... ALIGN_UP(x) - x ...
>
> you mean
>
> ALIGN_UP(x, PAGES_PER_SECTION) - x
>
> but ...
>
> > which is better *without* having a separate name. Does that not
> > generate good machine code for you?
>
> 1. There is no ALIGN_UP. "SECTION_ALIGN_UP(x) - x" would be possible
Erm, you started it ;-)
> 2. It would be wrong if x is already aligned.
>
> e.g., let's use 4096 for simplicity as we all know that value by heart
> (for both x and the block size).
>
> a) -(4096 | -4096) -> 4096
>
> b) #define ALIGN_UP(x, a) ((x + a - 1) & -(a))
>
> ALIGN_UP(4096, 4096) - 4096 -> 0
>
> Not as easy as it seems ...
If you always want to return a number >= 1, it it simply
ALIGN_UP(x + 1) - x
(and replace 1 by any other minimum size required). This *also* is
easy to read, without having to have any details (and quirks :-/ )
of those utility functions memorised.
Segher
WARNING: multiple messages have this Message-ID (diff)
From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Hildenbrand <david@redhat.com>
Cc: linux-s390@vger.kernel.org, Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org,
Pavel Tatashin <pasha.tatashin@soleen.com>,
linux-sh@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Wei Yang <richardw.yang@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
Dan Williams <dan.j.williams@intel.com>,
linux-arm-kernel@lists.infradead.org,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages()
Date: Wed, 5 Feb 2020 06:51:49 -0600 [thread overview]
Message-ID: <20200205125149.GS22482@gate.crashing.org> (raw)
In-Reply-To: <0e2f700c-b01b-8c16-99c2-2648967fc203@redhat.com>
On Tue, Feb 04, 2020 at 02:38:51PM +0100, David Hildenbrand wrote:
> On 04.02.20 14:13, Segher Boessenkool wrote:
> > On Tue, Feb 04, 2020 at 01:41:06PM +0100, David Hildenbrand wrote:
> >> It's a pattern commonly used in compilers and emulators to calculate the
> >> number of bytes to the next block/alignment. (we're missing a macro
> >> (like we have ALIGN_UP/IS_ALIGNED) for that - but it's hard to come up
> >> with a good name (e.g., SIZE_TO_NEXT_ALIGN) .
> > You can just write the easy to understand
> >
> > ... ALIGN_UP(x) - x ...
>
> you mean
>
> ALIGN_UP(x, PAGES_PER_SECTION) - x
>
> but ...
>
> > which is better *without* having a separate name. Does that not
> > generate good machine code for you?
>
> 1. There is no ALIGN_UP. "SECTION_ALIGN_UP(x) - x" would be possible
Erm, you started it ;-)
> 2. It would be wrong if x is already aligned.
>
> e.g., let's use 4096 for simplicity as we all know that value by heart
> (for both x and the block size).
>
> a) -(4096 | -4096) -> 4096
>
> b) #define ALIGN_UP(x, a) ((x + a - 1) & -(a))
>
> ALIGN_UP(4096, 4096) - 4096 -> 0
>
> Not as easy as it seems ...
If you always want to return a number >= 1, it it simply
ALIGN_UP(x + 1) - x
(and replace 1 by any other minimum size required). This *also* is
easy to read, without having to have any details (and quirks :-/ )
of those utility functions memorised.
Segher
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-02-05 12:51 UTC|newest]
Thread overview: 261+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-06 8:56 [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` [PATCH v6 01/10] mm/memunmap: Don't access uninitialized memmap in memunmap_pages() David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 19:58 ` Damian Tometzki
2019-10-06 19:58 ` Damian Tometzki
2019-10-06 19:58 ` Damian Tometzki
2019-10-06 19:58 ` Damian Tometzki
2019-10-06 20:13 ` David Hildenbrand
2019-10-06 20:13 ` David Hildenbrand
2019-10-06 20:13 ` David Hildenbrand
2019-10-14 9:05 ` David Hildenbrand
2019-10-14 9:05 ` David Hildenbrand
2019-10-14 9:05 ` David Hildenbrand
2019-10-14 9:05 ` David Hildenbrand
2019-10-06 8:56 ` [PATCH v6 02/10] mm/memmap_init: Update variable name in memmap_init_zone David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` [PATCH v6 03/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_pgdat_span() David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-14 9:31 ` David Hildenbrand
2019-10-14 9:31 ` David Hildenbrand
2019-10-14 9:31 ` David Hildenbrand
2019-10-14 9:31 ` David Hildenbrand
2019-10-06 8:56 ` [PATCH v6 04/10] mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span() David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-14 9:32 ` David Hildenbrand
2019-10-14 9:32 ` David Hildenbrand
2019-10-14 9:32 ` David Hildenbrand
2019-10-14 9:32 ` David Hildenbrand
2019-10-14 19:17 ` Andrew Morton
2019-10-14 19:17 ` Andrew Morton
2019-10-14 19:17 ` Andrew Morton
2019-10-14 19:17 ` Andrew Morton
2019-11-19 14:16 ` David Hildenbrand
2019-11-19 14:16 ` David Hildenbrand
2019-11-19 14:16 ` David Hildenbrand
2019-11-19 14:16 ` David Hildenbrand
2019-11-19 20:44 ` Andrew Morton
2019-11-19 20:44 ` Andrew Morton
2019-11-19 20:44 ` Andrew Morton
2019-11-19 20:44 ` Andrew Morton
2019-10-06 8:56 ` [PATCH v6 05/10] mm/memory_hotplug: Shrink zones when offlining memory David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-14 9:39 ` David Hildenbrand
2019-10-14 9:39 ` David Hildenbrand
2019-10-14 19:16 ` Andrew Morton
2019-10-14 19:16 ` Andrew Morton
2019-10-27 22:45 ` David Hildenbrand
2019-10-27 22:45 ` David Hildenbrand
2019-11-30 23:21 ` Andrew Morton
2019-11-30 23:21 ` Andrew Morton
2019-11-30 23:43 ` David Hildenbrand
2019-11-30 23:43 ` David Hildenbrand
2019-12-18 17:08 ` David Hildenbrand
2019-12-18 17:08 ` David Hildenbrand
2019-12-18 20:16 ` Andrew Morton
2019-12-18 20:16 ` Andrew Morton
2019-12-03 15:10 ` Oscar Salvador
2019-12-03 15:10 ` Oscar Salvador
2019-12-03 15:27 ` David Hildenbrand
2019-12-03 15:27 ` David Hildenbrand
2019-12-03 15:27 ` David Hildenbrand
2019-12-03 15:27 ` David Hildenbrand
2019-10-06 8:56 ` [PATCH v6 06/10] mm/memory_hotplug: Poison memmap in remove_pfn_range_from_zone() David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-16 14:01 ` David Hildenbrand
2019-10-16 14:01 ` David Hildenbrand
2019-10-16 14:01 ` David Hildenbrand
2019-10-16 14:01 ` David Hildenbrand
2020-02-04 8:59 ` Oscar Salvador
2020-02-04 8:59 ` Oscar Salvador
2020-02-04 8:59 ` Oscar Salvador
2020-02-04 8:59 ` Oscar Salvador
2019-10-06 8:56 ` [PATCH v6 07/10] mm/memory_hotplug: We always have a zone in find_(smallest|biggest)_section_pfn David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2020-02-04 9:06 ` Oscar Salvador
2020-02-04 9:06 ` Oscar Salvador
2020-02-04 9:06 ` Oscar Salvador
2020-02-04 9:06 ` Oscar Salvador
2020-02-05 8:57 ` Wei Yang
2020-02-05 8:57 ` Wei Yang
2020-02-05 8:57 ` Wei Yang
2020-02-05 8:57 ` Wei Yang
2020-02-05 8:59 ` David Hildenbrand
2020-02-05 8:59 ` David Hildenbrand
2020-02-05 8:59 ` David Hildenbrand
2020-02-05 8:59 ` David Hildenbrand
2020-02-05 9:26 ` Wei Yang
2020-02-05 9:26 ` Wei Yang
2020-02-05 9:26 ` Wei Yang
2020-02-05 9:26 ` Wei Yang
2019-10-06 8:56 ` [PATCH v6 08/10] mm/memory_hotplug: Don't check for "all holes" in shrink_zone_span() David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2020-02-04 9:13 ` Oscar Salvador
2020-02-04 9:13 ` Oscar Salvador
2020-02-04 9:13 ` Oscar Salvador
2020-02-04 9:13 ` Oscar Salvador
2020-02-04 9:20 ` David Hildenbrand
2020-02-04 9:20 ` David Hildenbrand
2020-02-04 9:20 ` David Hildenbrand
2020-02-04 9:20 ` David Hildenbrand
2020-02-04 14:25 ` Baoquan He
2020-02-04 14:25 ` Baoquan He
2020-02-04 14:25 ` Baoquan He
2020-02-04 14:25 ` Baoquan He
2020-02-04 14:42 ` David Hildenbrand
2020-02-04 14:42 ` David Hildenbrand
2020-02-04 14:42 ` David Hildenbrand
2020-02-04 14:42 ` David Hildenbrand
2020-02-05 12:43 ` Baoquan He
2020-02-05 12:43 ` Baoquan He
2020-02-05 12:43 ` Baoquan He
2020-02-05 12:43 ` Baoquan He
2020-02-05 13:20 ` David Hildenbrand
2020-02-05 13:20 ` David Hildenbrand
2020-02-05 13:20 ` David Hildenbrand
2020-02-05 13:20 ` David Hildenbrand
2020-02-05 13:34 ` Baoquan He
2020-02-05 13:34 ` Baoquan He
2020-02-05 13:34 ` Baoquan He
2020-02-05 13:34 ` Baoquan He
2020-02-05 13:38 ` David Hildenbrand
2020-02-05 13:38 ` David Hildenbrand
2020-02-05 13:38 ` David Hildenbrand
2020-02-05 13:38 ` David Hildenbrand
2020-02-05 14:12 ` Baoquan He
2020-02-05 14:12 ` Baoquan He
2020-02-05 14:12 ` Baoquan He
2020-02-05 14:12 ` Baoquan He
2020-02-05 14:16 ` David Hildenbrand
2020-02-05 14:16 ` David Hildenbrand
2020-02-05 14:16 ` David Hildenbrand
2020-02-05 14:16 ` David Hildenbrand
2020-02-05 14:26 ` Baoquan He
2020-02-05 14:26 ` Baoquan He
2020-02-05 14:26 ` Baoquan He
2020-02-05 14:26 ` Baoquan He
2020-02-05 9:59 ` Wei Yang
2020-02-05 9:59 ` Wei Yang
2020-02-05 9:59 ` Wei Yang
2020-02-05 9:59 ` Wei Yang
2020-02-05 14:48 ` Baoquan He
2020-02-05 14:48 ` Baoquan He
2020-02-05 14:48 ` Baoquan He
2020-02-05 14:48 ` Baoquan He
2020-02-05 22:56 ` Wei Yang
2020-02-05 22:56 ` Wei Yang
2020-02-05 22:56 ` Wei Yang
2020-02-05 22:56 ` Wei Yang
2020-02-05 23:08 ` Baoquan He
2020-02-05 23:08 ` Baoquan He
2020-02-05 23:08 ` Baoquan He
2020-02-05 23:08 ` Baoquan He
2020-02-05 23:26 ` Wei Yang
2020-02-05 23:26 ` Wei Yang
2020-02-05 23:26 ` Wei Yang
2020-02-05 23:26 ` Wei Yang
2020-02-05 23:30 ` Baoquan He
2020-02-05 23:30 ` Baoquan He
2020-02-05 23:30 ` Baoquan He
2020-02-05 23:30 ` Baoquan He
2020-02-05 23:34 ` Wei Yang
2020-02-05 23:34 ` Wei Yang
2020-02-05 23:34 ` Wei Yang
2020-02-05 23:34 ` Wei Yang
2020-02-05 14:54 ` David Laight
2020-02-05 14:54 ` David Laight
2020-02-05 14:54 ` David Laight
2020-02-05 14:54 ` David Laight
2020-02-05 14:55 ` David Hildenbrand
2020-02-05 14:55 ` David Hildenbrand
2020-02-05 14:55 ` David Hildenbrand
2020-02-05 14:55 ` David Hildenbrand
2019-10-06 8:56 ` [PATCH v6 09/10] mm/memory_hotplug: Drop local variables " David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2020-02-04 9:26 ` Oscar Salvador
2020-02-04 9:26 ` Oscar Salvador
2020-02-04 9:26 ` Oscar Salvador
2020-02-04 9:26 ` Oscar Salvador
2020-02-04 9:29 ` David Hildenbrand
2020-02-04 9:29 ` David Hildenbrand
2020-02-04 9:29 ` David Hildenbrand
2020-02-04 9:29 ` David Hildenbrand
2020-02-05 10:07 ` Wei Yang
2020-02-05 10:07 ` Wei Yang
2020-02-05 10:07 ` Wei Yang
2020-02-05 10:07 ` Wei Yang
2019-10-06 8:56 ` [PATCH v6 10/10] mm/memory_hotplug: Cleanup __remove_pages() David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2019-10-06 8:56 ` David Hildenbrand
2020-02-04 9:46 ` Oscar Salvador
2020-02-04 9:46 ` Oscar Salvador
2020-02-04 9:46 ` Oscar Salvador
2020-02-04 9:46 ` Oscar Salvador
2020-02-04 12:41 ` David Hildenbrand
2020-02-04 12:41 ` David Hildenbrand
2020-02-04 12:41 ` David Hildenbrand
2020-02-04 12:41 ` David Hildenbrand
2020-02-04 13:13 ` Segher Boessenkool
2020-02-04 13:13 ` Segher Boessenkool
2020-02-04 13:13 ` Segher Boessenkool
2020-02-04 13:13 ` Segher Boessenkool
2020-02-04 13:38 ` David Hildenbrand
2020-02-04 13:38 ` David Hildenbrand
2020-02-04 13:38 ` David Hildenbrand
2020-02-04 13:38 ` David Hildenbrand
2020-02-05 12:51 ` Segher Boessenkool [this message]
2020-02-05 12:51 ` Segher Boessenkool
2020-02-05 12:51 ` Segher Boessenkool
2020-02-05 12:51 ` Segher Boessenkool
2020-02-05 13:17 ` David Hildenbrand
2020-02-05 13:17 ` David Hildenbrand
2020-02-05 13:17 ` David Hildenbrand
2020-02-05 13:17 ` David Hildenbrand
2020-02-05 13:18 ` David Hildenbrand
2020-02-05 13:18 ` David Hildenbrand
2020-02-05 13:18 ` David Hildenbrand
2020-02-05 13:18 ` David Hildenbrand
2020-02-05 13:23 ` David Hildenbrand
2020-02-05 13:23 ` David Hildenbrand
2020-02-05 13:23 ` David Hildenbrand
2020-02-05 13:23 ` David Hildenbrand
2020-02-05 11:48 ` Wei Yang
2020-02-05 11:48 ` Wei Yang
2020-02-05 11:48 ` Wei Yang
2020-02-05 11:48 ` Wei Yang
2019-12-02 9:09 ` [PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory David Hildenbrand
2019-12-02 9:09 ` David Hildenbrand
2019-12-03 13:36 ` Oscar Salvador
2019-12-03 13:36 ` Oscar Salvador
2020-01-31 4:40 ` Andrew Morton
2020-01-31 4:40 ` Andrew Morton
2020-01-31 9:18 ` David Hildenbrand
2020-01-31 9:18 ` David Hildenbrand
2020-01-31 10:03 ` Michal Hocko
2020-01-31 10:03 ` Michal Hocko
2020-01-31 10:36 ` David Hildenbrand
2020-01-31 10:36 ` David Hildenbrand
2020-02-04 1:46 ` Andrew Morton
2020-02-04 1:46 ` Andrew Morton
2020-02-04 8:45 ` David Hildenbrand
2020-02-04 8:45 ` David Hildenbrand
2020-02-04 9:51 ` Oscar Salvador
2020-02-04 9:51 ` 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=20200205125149.GS22482@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=richardw.yang@linux.intel.com \
--cc=x86@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 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.