From: Andrew Morton <akpm@linux-foundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-pm@lists.linux-foundation.org, fengguang.wu@intel.com,
linux-kernel@vger.kernel.org, pavel@ucw.cz, nigel@tuxonice.net,
rientjes@google.com, linux-mm@kvack.org
Subject: Re: [PATCH 4/6] PM/Hibernate: Rework shrinking of memory
Date: Wed, 13 May 2009 12:34:09 -0700 [thread overview]
Message-ID: <20090513123409.302f4307.akpm@linux-foundation.org> (raw)
In-Reply-To: <200905131039.26778.rjw@sisk.pl>
On Wed, 13 May 2009 10:39:25 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> Rework swsusp_shrink_memory() so that it calls shrink_all_memory()
> just once to make some room for the image and then allocates memory
> to apply more pressure to the memory management subsystem, if
> necessary.
>
> Unfortunately, we don't seem to be able to drop shrink_all_memory()
> entirely just yet, because that would lead to huge performance
> regressions in some test cases.
>
Isn't this a somewhat large problem? The main point (I thought) was
to remove shrink_all_memory(). Instead, we're retaining it and adding
even more stuff?
> +/**
> + * compute_fraction - Compute approximate fraction x * (a/b)
> + * @x: Number to multiply.
> + * @numerator: Numerator of the fraction (a).
> + * @denominator: Denominator of the fraction (b).
> *
> - * Notice: all userland should be stopped before it is called, or
> - * livelock is possible.
> + * Compute an approximate value of the expression x * (a/b), where a is less
> + * than b, all x, a, b are unsigned longs and x * a may be greater than the
> + * maximum unsigned long.
> */
> +static unsigned long compute_fraction(
> + unsigned long x, unsigned long numerator, unsigned long denominator)
I can't say I'm a great fan of the code layout here.
static unsigned long compute_fraction(unsigned long x, unsigned long numerator, unsigned long denominator)
or
static unsigned long compute_fraction(unsigned long x, unsigned long numerator,
unsigned long denominator)
would be more typical.
> +{
> + unsigned long ratio = (numerator << FRACTION_SHIFT) / denominator;
>
> -#define SHRINK_BITE 10000
> -static inline unsigned long __shrink_memory(long tmp)
> + x *= ratio;
> + return x >> FRACTION_SHIFT;
> +}
Strange function. Would it not be simpler/clearer to do it with 64-bit
scalars, multiplication and do_div()?
> +static unsigned long highmem_size(
> + unsigned long size, unsigned long highmem, unsigned long count)
> +{
> + return highmem > count / 2 ?
> + compute_fraction(size, highmem, count) :
> + size - compute_fraction(size, count - highmem, count);
> +}
This would be considerably easier to follow if we know what the three
arguments represent. Amount of memory? In what units? `count' of
what?
The `count/2' thing there is quite mysterious.
<does some reverse-engineering>
OK, `count' is "the number of pageframes we can use". (I don't think I
helped myself a lot there). But what's up with that divde-by-two?
<considers poking at callers to work out what `size' is>
<gives up>
Is this code as clear as we can possibly make it??
> +#else
> +static inline unsigned long preallocate_image_highmem(unsigned long nr_pages)
> +{
> + return 0;
> +}
> +
> +static inline unsigned long highmem_size(
> + unsigned long size, unsigned long highmem, unsigned long count)
> {
> - if (tmp > SHRINK_BITE)
> - tmp = SHRINK_BITE;
> - return shrink_all_memory(tmp);
> + return 0;
> }
> +#endif /* CONFIG_HIGHMEM */
>
> +/**
> + * swsusp_shrink_memory - Make the kernel release as much memory as needed
> + *
> + * To create a hibernation image it is necessary to make a copy of every page
> + * frame in use. We also need a number of page frames to be free during
> + * hibernation for allocations made while saving the image and for device
> + * drivers, in case they need to allocate memory from their hibernation
> + * callbacks (these two numbers are given by PAGES_FOR_IO and SPARE_PAGES,
> + * respectively, both of which are rough estimates). To make this happen, we
> + * compute the total number of available page frames and allocate at least
> + *
> + * ([page frames total] + PAGES_FOR_IO + [metadata pages]) / 2 + 2 * SPARE_PAGES
> + *
> + * of them, which corresponds to the maximum size of a hibernation image.
> + *
> + * If image_size is set below the number following from the above formula,
> + * the preallocation of memory is continued until the total number of saveable
> + * pages in the system is below the requested image size or it is impossible to
> + * allocate more memory, whichever happens first.
> + */
OK, that helps.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-pm@lists.linux-foundation.org, fengguang.wu@intel.com,
linux-kernel@vger.kernel.org, pavel@ucw.cz, nigel@tuxonice.net,
rientjes@google.com, linux-mm@kvack.org
Subject: Re: [PATCH 4/6] PM/Hibernate: Rework shrinking of memory
Date: Wed, 13 May 2009 12:34:09 -0700 [thread overview]
Message-ID: <20090513123409.302f4307.akpm@linux-foundation.org> (raw)
In-Reply-To: <200905131039.26778.rjw@sisk.pl>
On Wed, 13 May 2009 10:39:25 +0200
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> From: Rafael J. Wysocki <rjw@sisk.pl>
>
> Rework swsusp_shrink_memory() so that it calls shrink_all_memory()
> just once to make some room for the image and then allocates memory
> to apply more pressure to the memory management subsystem, if
> necessary.
>
> Unfortunately, we don't seem to be able to drop shrink_all_memory()
> entirely just yet, because that would lead to huge performance
> regressions in some test cases.
>
Isn't this a somewhat large problem? The main point (I thought) was
to remove shrink_all_memory(). Instead, we're retaining it and adding
even more stuff?
> +/**
> + * compute_fraction - Compute approximate fraction x * (a/b)
> + * @x: Number to multiply.
> + * @numerator: Numerator of the fraction (a).
> + * @denominator: Denominator of the fraction (b).
> *
> - * Notice: all userland should be stopped before it is called, or
> - * livelock is possible.
> + * Compute an approximate value of the expression x * (a/b), where a is less
> + * than b, all x, a, b are unsigned longs and x * a may be greater than the
> + * maximum unsigned long.
> */
> +static unsigned long compute_fraction(
> + unsigned long x, unsigned long numerator, unsigned long denominator)
I can't say I'm a great fan of the code layout here.
static unsigned long compute_fraction(unsigned long x, unsigned long numerator, unsigned long denominator)
or
static unsigned long compute_fraction(unsigned long x, unsigned long numerator,
unsigned long denominator)
would be more typical.
> +{
> + unsigned long ratio = (numerator << FRACTION_SHIFT) / denominator;
>
> -#define SHRINK_BITE 10000
> -static inline unsigned long __shrink_memory(long tmp)
> + x *= ratio;
> + return x >> FRACTION_SHIFT;
> +}
Strange function. Would it not be simpler/clearer to do it with 64-bit
scalars, multiplication and do_div()?
> +static unsigned long highmem_size(
> + unsigned long size, unsigned long highmem, unsigned long count)
> +{
> + return highmem > count / 2 ?
> + compute_fraction(size, highmem, count) :
> + size - compute_fraction(size, count - highmem, count);
> +}
This would be considerably easier to follow if we know what the three
arguments represent. Amount of memory? In what units? `count' of
what?
The `count/2' thing there is quite mysterious.
<does some reverse-engineering>
OK, `count' is "the number of pageframes we can use". (I don't think I
helped myself a lot there). But what's up with that divde-by-two?
<considers poking at callers to work out what `size' is>
<gives up>
Is this code as clear as we can possibly make it??
> +#else
> +static inline unsigned long preallocate_image_highmem(unsigned long nr_pages)
> +{
> + return 0;
> +}
> +
> +static inline unsigned long highmem_size(
> + unsigned long size, unsigned long highmem, unsigned long count)
> {
> - if (tmp > SHRINK_BITE)
> - tmp = SHRINK_BITE;
> - return shrink_all_memory(tmp);
> + return 0;
> }
> +#endif /* CONFIG_HIGHMEM */
>
> +/**
> + * swsusp_shrink_memory - Make the kernel release as much memory as needed
> + *
> + * To create a hibernation image it is necessary to make a copy of every page
> + * frame in use. We also need a number of page frames to be free during
> + * hibernation for allocations made while saving the image and for device
> + * drivers, in case they need to allocate memory from their hibernation
> + * callbacks (these two numbers are given by PAGES_FOR_IO and SPARE_PAGES,
> + * respectively, both of which are rough estimates). To make this happen, we
> + * compute the total number of available page frames and allocate at least
> + *
> + * ([page frames total] + PAGES_FOR_IO + [metadata pages]) / 2 + 2 * SPARE_PAGES
> + *
> + * of them, which corresponds to the maximum size of a hibernation image.
> + *
> + * If image_size is set below the number following from the above formula,
> + * the preallocation of memory is continued until the total number of saveable
> + * pages in the system is below the requested image size or it is impossible to
> + * allocate more memory, whichever happens first.
> + */
OK, that helps.
--
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:[~2009-05-13 19:40 UTC|newest]
Thread overview: 205+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-06 22:40 [RFC][PATCH 0/5] PM/Hibernate: Rework memory shrinking Rafael J. Wysocki
2009-05-06 22:41 ` [RFC][PATCH 1/5] PM/Freezer: Disable OOM killer when tasks are frozen Rafael J. Wysocki
2009-05-06 22:41 ` Rafael J. Wysocki
2009-05-06 23:00 ` Nigel Cunningham
2009-05-06 23:00 ` Nigel Cunningham
2009-05-07 12:10 ` Rafael J. Wysocki
2009-05-07 12:10 ` Rafael J. Wysocki
2009-05-07 0:36 ` [linux-pm] [RFC][PATCH 1/5] PM/Freezer: Disable OOM killer whentasks " Matt Helsley
2009-05-07 12:09 ` Rafael J. Wysocki
2009-05-07 12:09 ` [linux-pm] " Rafael J. Wysocki
2009-05-07 0:36 ` Matt Helsley
2009-05-06 22:42 ` [RFC][PATCH 2/5] PM/Suspend: Do not shrink memory before suspend Rafael J. Wysocki
2009-05-06 22:42 ` Rafael J. Wysocki
2009-05-06 23:01 ` Nigel Cunningham
2009-05-06 23:01 ` Nigel Cunningham
2009-05-06 22:42 ` [RFC][PATCH 3/5] PM/Hibernate: Move memory shrinking to snapshot.c (rev. 2) Rafael J. Wysocki
2009-05-06 22:42 ` Rafael J. Wysocki
2009-05-06 22:44 ` [RFC][PATCH 4/5] PM/Hibernate: Rework shrinking of memory Rafael J. Wysocki
2009-05-06 23:27 ` Nigel Cunningham
2009-05-07 12:18 ` Rafael J. Wysocki
2009-05-07 12:18 ` Rafael J. Wysocki
2009-05-07 20:00 ` Rafael J. Wysocki
2009-05-07 20:53 ` Nigel Cunningham
2009-05-07 20:53 ` Nigel Cunningham
2009-05-07 20:00 ` Rafael J. Wysocki
2009-05-07 20:51 ` Nigel Cunningham
2009-05-07 20:51 ` Nigel Cunningham
2009-05-06 23:27 ` Nigel Cunningham
2009-05-06 22:44 ` Rafael J. Wysocki
2009-05-06 22:48 ` [RFC][PATCH 5/5] PM/Hibernate: Do not release preallocated memory unnecessarily Rafael J. Wysocki
2009-05-06 22:48 ` Rafael J. Wysocki
2009-05-07 21:48 ` [RFC][PATCH 0/5] PM/Hibernate: Rework memory shrinking (rev. 2) Rafael J. Wysocki
2009-05-07 21:48 ` Rafael J. Wysocki
2009-05-07 21:48 ` Rafael J. Wysocki
2009-05-07 21:50 ` [RFC][PATCH 1/5] mm: Introduce __GFP_NO_OOM_KILL Rafael J. Wysocki
2009-05-07 21:50 ` Rafael J. Wysocki
2009-05-07 22:24 ` [RFC][PATCH] PM/Freezer: Disable OOM killer when tasks are frozen (was: Re: [RFC][PATCH 1/5] mm: Introduce __GFP_NO_OOM_KILL) Rafael J. Wysocki
2009-05-07 22:24 ` Rafael J. Wysocki
2009-05-07 22:24 ` Rafael J. Wysocki
2009-05-07 21:50 ` [RFC][PATCH 1/5] mm: Introduce __GFP_NO_OOM_KILL Rafael J. Wysocki
2009-05-07 21:51 ` [RFC][PATCH 2/5] PM/Suspend: Do not shrink memory before suspend Rafael J. Wysocki
2009-05-07 21:51 ` Rafael J. Wysocki
2009-05-08 8:52 ` Wu Fengguang
2009-05-08 8:52 ` Wu Fengguang
2009-05-08 8:52 ` Wu Fengguang
2009-05-07 21:51 ` Rafael J. Wysocki
2009-05-07 21:51 ` [RFC][PATCH 3/5] PM/Hibernate: Move memory shrinking to snapshot.c (rev. 2) Rafael J. Wysocki
2009-05-07 21:51 ` Rafael J. Wysocki
2009-05-07 21:51 ` Rafael J. Wysocki
2009-05-08 8:53 ` Wu Fengguang
2009-05-08 8:53 ` Wu Fengguang
2009-05-08 8:53 ` Wu Fengguang
2009-05-07 21:53 ` [RFC][PATCH 4/5] PM/Hibernate: Rework shrinking of memory Rafael J. Wysocki
2009-05-07 21:53 ` Rafael J. Wysocki
2009-05-07 21:53 ` Rafael J. Wysocki
2009-05-07 21:55 ` [RFC][PATCH 5/5] PM/Hibernate: Do not release preallocated memory unnecessarily Rafael J. Wysocki
2009-05-07 21:55 ` Rafael J. Wysocki
2009-05-07 21:55 ` Rafael J. Wysocki
2009-05-10 13:48 ` [RFC][PATCH 0/6] PM/Hibernate: Rework memory shrinking (rev. 3) Rafael J. Wysocki
2009-05-10 13:48 ` Rafael J. Wysocki
2009-05-10 13:50 ` [RFC][PATCH 1/6] mm: Introduce __GFP_NO_OOM_KILL Rafael J. Wysocki
2009-05-10 13:50 ` Rafael J. Wysocki
2009-05-11 20:12 ` David Rientjes
2009-05-11 20:12 ` David Rientjes
2009-05-11 22:14 ` Rafael J. Wysocki
2009-05-11 22:14 ` Rafael J. Wysocki
2009-05-11 22:33 ` Andrew Morton
2009-05-11 22:33 ` Andrew Morton
2009-05-11 22:33 ` Andrew Morton
2009-05-11 23:04 ` Rafael J. Wysocki
2009-05-11 23:04 ` Rafael J. Wysocki
2009-05-11 23:04 ` Rafael J. Wysocki
2009-05-11 22:14 ` Rafael J. Wysocki
2009-05-11 20:12 ` David Rientjes
2009-05-10 13:50 ` Rafael J. Wysocki
2009-05-10 13:50 ` [RFC][PATCH 2/6] PM/Suspend: Do not shrink memory before suspend Rafael J. Wysocki
2009-05-10 13:50 ` Rafael J. Wysocki
2009-05-10 13:50 ` Rafael J. Wysocki
2009-05-10 13:51 ` [RFC][PATCH 3/6] PM/Hibernate: Move memory shrinking to snapshot.c (rev. 2) Rafael J. Wysocki
2009-05-10 13:51 ` Rafael J. Wysocki
2009-05-10 13:51 ` Rafael J. Wysocki
2009-05-10 13:53 ` [RFC][PATCH 4/6] PM/Hibernate: Rework shrinking of memory Rafael J. Wysocki
2009-05-10 13:53 ` Rafael J. Wysocki
2009-05-10 13:53 ` Rafael J. Wysocki
2009-05-10 13:57 ` [RFC][PATCH 5/6] PM/Hibernate: Do not release preallocated memory unnecessarily Rafael J. Wysocki
2009-05-10 13:57 ` Rafael J. Wysocki
2009-05-10 19:49 ` Rafael J. Wysocki
2009-05-10 19:49 ` Rafael J. Wysocki
2009-05-10 19:49 ` Rafael J. Wysocki
2009-05-10 13:57 ` Rafael J. Wysocki
2009-05-10 14:12 ` [RFC][PATCH 6/6] PM/Hibernate: Estimate hard core working set size Rafael J. Wysocki
2009-05-10 14:12 ` Rafael J. Wysocki
2009-05-10 14:12 ` Rafael J. Wysocki
2009-05-10 19:53 ` Rafael J. Wysocki
2009-05-10 19:53 ` Rafael J. Wysocki
2009-05-10 19:53 ` Rafael J. Wysocki
2009-05-13 8:32 ` [RFC][PATCH 0/6] PM/Hibernate: Rework memory shrinking (rev. 4) Rafael J. Wysocki
2009-05-13 8:32 ` Rafael J. Wysocki
2009-05-13 8:32 ` Rafael J. Wysocki
2009-05-13 8:34 ` [PATCH 1/6] PM/Suspend: Do not shrink memory before suspend Rafael J. Wysocki
2009-05-13 8:34 ` Rafael J. Wysocki
2009-05-13 8:34 ` Rafael J. Wysocki
2009-05-13 8:35 ` [PATCH 2/6] PM/Hibernate: Move memory shrinking to snapshot.c (rev. 2) Rafael J. Wysocki
2009-05-13 8:35 ` Rafael J. Wysocki
2009-05-13 8:35 ` Rafael J. Wysocki
2009-05-13 8:37 ` [PATCH 3/6] mm, PM/Freezer: Disable OOM killer when tasks are frozen Rafael J. Wysocki
2009-05-13 8:37 ` Rafael J. Wysocki
2009-05-13 9:19 ` Pavel Machek
2009-05-13 9:19 ` Pavel Machek
2009-05-13 9:19 ` Pavel Machek
2009-05-13 22:35 ` David Rientjes
2009-05-13 22:35 ` David Rientjes
2009-05-13 22:47 ` Andrew Morton
2009-05-13 22:47 ` Andrew Morton
2009-05-13 23:01 ` David Rientjes
2009-05-13 23:01 ` David Rientjes
2009-05-13 23:01 ` David Rientjes
2009-05-13 22:47 ` Andrew Morton
2009-05-13 22:35 ` David Rientjes
2009-05-13 8:37 ` Rafael J. Wysocki
2009-05-13 8:39 ` [PATCH 4/6] PM/Hibernate: Rework shrinking of memory Rafael J. Wysocki
2009-05-13 8:39 ` Rafael J. Wysocki
2009-05-13 8:39 ` Rafael J. Wysocki
2009-05-13 19:34 ` Andrew Morton
2009-05-13 19:34 ` Andrew Morton [this message]
2009-05-13 19:34 ` Andrew Morton
2009-05-13 20:55 ` Rafael J. Wysocki
2009-05-13 20:55 ` Rafael J. Wysocki
2009-05-13 20:55 ` Rafael J. Wysocki
2009-05-13 21:16 ` Andrew Morton
2009-05-13 21:16 ` Andrew Morton
2009-05-13 21:16 ` Andrew Morton
2009-05-13 21:56 ` Rafael J. Wysocki
2009-05-13 21:56 ` Rafael J. Wysocki
2009-05-14 9:40 ` Pavel Machek
2009-05-14 9:40 ` Pavel Machek
2009-05-14 9:40 ` Pavel Machek
2009-05-14 17:49 ` Rafael J. Wysocki
2009-05-14 17:49 ` Rafael J. Wysocki
2009-05-15 13:09 ` Pavel Machek
2009-05-15 13:09 ` Pavel Machek
2009-05-15 13:09 ` Pavel Machek
2009-05-14 17:49 ` Rafael J. Wysocki
2009-05-13 21:56 ` Rafael J. Wysocki
2009-05-14 18:26 ` Rafael J. Wysocki
2009-05-14 18:26 ` Rafael J. Wysocki
2009-05-14 18:26 ` Rafael J. Wysocki
2009-05-13 8:40 ` [PATCH 5/6] PM/Hibernate: Do not release preallocated memory unnecessarily (rev. 2) Rafael J. Wysocki
2009-05-13 8:40 ` Rafael J. Wysocki
2009-05-14 11:09 ` Pavel Machek
2009-05-14 11:09 ` Pavel Machek
2009-05-14 17:52 ` Rafael J. Wysocki
2009-05-14 17:52 ` Rafael J. Wysocki
2009-05-14 17:52 ` Rafael J. Wysocki
2009-05-15 13:11 ` Pavel Machek
2009-05-15 13:11 ` Pavel Machek
2009-05-15 13:11 ` Pavel Machek
2009-05-15 14:52 ` Rafael J. Wysocki
2009-05-15 14:52 ` Rafael J. Wysocki
2009-05-15 14:52 ` Rafael J. Wysocki
2009-05-14 11:09 ` Pavel Machek
2009-05-13 8:40 ` Rafael J. Wysocki
2009-05-13 8:42 ` [RFC][PATCH 6/6] PM/Hibernate: Do not try to allocate too much memory too hard Rafael J. Wysocki
2009-05-13 8:42 ` Rafael J. Wysocki
2009-05-13 8:42 ` Rafael J. Wysocki
2009-05-14 11:14 ` Pavel Machek
2009-05-14 11:14 ` Pavel Machek
2009-05-14 17:59 ` Rafael J. Wysocki
2009-05-14 17:59 ` Rafael J. Wysocki
2009-05-14 17:59 ` Rafael J. Wysocki
2009-05-15 13:14 ` Pavel Machek
2009-05-15 13:14 ` Pavel Machek
2009-05-15 13:14 ` Pavel Machek
2009-05-15 14:40 ` Rafael J. Wysocki
2009-05-15 14:40 ` Rafael J. Wysocki
2009-05-15 14:40 ` Rafael J. Wysocki
2009-05-14 11:14 ` Pavel Machek
2009-05-17 12:06 ` Wu Fengguang
2009-05-17 12:06 ` Wu Fengguang
2009-05-17 12:06 ` Wu Fengguang
2009-05-17 12:55 ` Rafael J. Wysocki
2009-05-17 12:55 ` Rafael J. Wysocki
2009-05-17 14:07 ` Wu Fengguang
2009-05-17 14:07 ` Wu Fengguang
2009-05-17 14:07 ` Wu Fengguang
2009-05-17 16:53 ` Rafael J. Wysocki
2009-05-17 16:53 ` Rafael J. Wysocki
2009-05-18 8:32 ` Wu Fengguang
2009-05-18 8:32 ` Wu Fengguang
2009-05-18 8:32 ` Wu Fengguang
2009-05-17 16:53 ` Rafael J. Wysocki
2009-05-17 21:14 ` Rafael J. Wysocki
2009-05-17 21:14 ` Rafael J. Wysocki
2009-05-17 21:14 ` Rafael J. Wysocki
2009-05-18 8:56 ` Wu Fengguang
2009-05-18 8:56 ` Wu Fengguang
2009-05-18 8:56 ` Wu Fengguang
2009-05-18 17:07 ` Rafael J. Wysocki
2009-05-18 17:07 ` Rafael J. Wysocki
2009-05-18 17:07 ` Rafael J. Wysocki
2009-05-19 0:47 ` Wu Fengguang
2009-05-19 0:47 ` Wu Fengguang
2009-05-19 0:47 ` Wu Fengguang
2009-05-17 12:55 ` Rafael J. Wysocki
2009-05-10 13:48 ` [RFC][PATCH 0/6] PM/Hibernate: Rework memory shrinking (rev. 3) Rafael J. Wysocki
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=20090513123409.302f4307.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=fengguang.wu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=nigel@tuxonice.net \
--cc=pavel@ucw.cz \
--cc=rientjes@google.com \
--cc=rjw@sisk.pl \
/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.