From: Vlastimil Babka <vbabka@suse.cz>
To: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Hocko <mhocko@kernel.org>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand
Date: Wed, 30 Sep 2015 16:02:19 +0200 [thread overview]
Message-ID: <560BEB6B.7050004@suse.cz> (raw)
In-Reply-To: <20150930082725.GL3068@techsingularity.net>
On 09/30/2015 10:27 AM, Mel Gorman wrote:
> On Tue, Sep 29, 2015 at 02:01:41PM -0700, Andrew Morton wrote:
>>> ...
>>>
>>> +/*
>>> + * Reserve a pageblock for exclusive use of high-order atomic allocations if
>>> + * there are no empty page blocks that contain a page with a suitable order
>>> + */
>>> +static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
>>> + unsigned int alloc_order)
>>> +{
>>> + int mt;
>>> + unsigned long max_managed, flags;
>>> +
>>> + /*
>>> + * Limit the number reserved to 1 pageblock or roughly 1% of a zone.
>>> + * Check is race-prone but harmless.
>>> + */
>>> + max_managed = (zone->managed_pages / 100) + pageblock_nr_pages;
>>> + if (zone->nr_reserved_highatomic >= max_managed)
>>> + return;
>>> +
>>> + /* Yoink! */
>>> + spin_lock_irqsave(&zone->lock, flags);
>>> +
>>> + mt = get_pageblock_migratetype(page);
>>> + if (mt != MIGRATE_HIGHATOMIC &&
>>> + !is_migrate_isolate(mt) && !is_migrate_cma(mt)) {
>>
>> Do the above checks really need to be inside zone->lock? I don't think
>> get_pageblock_migratetype() needs zone->lock? (Actually I suspect it
>> does, but we don't...)
>>
>
> The get_pageblock_migratetype does not require zone->lock but it's race-prone
> without it and there have been cases (CMA, isolation) that cared. In this
> case, without the lock two parallel allocations may try to reserve the same
> block so we'd have to recheck the type under the lock to avoid corrupting
> nr_reserved_highatomic. As the move between free lists absolutely requires
> the zone->lock, it's best to just do the full operation under the lock.
>
>>> + zone->nr_reserved_highatomic += pageblock_nr_pages;
>>
>> And I don't think it would hurt to recheck
>> nr_reserved_highatomic>=max_managed after taking zone->lock, to plug
>> that race. We've had VM we-dont-care races in the past which ended up
>> causing problems in rare circumstances...
>>
>
> That makes sense, patch is below.
>
>>> + set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
>>> + move_freepages_block(zone, page, MIGRATE_HIGHATOMIC);
>>> + }
>>> + spin_unlock_irqrestore(&zone->lock, flags);
>>> +}
>>> +
>>> +/*
>>> + * Used when an allocation is about to fail under memory pressure. This
>>> + * potentially hurts the reliability of high-order allocations when under
>>> + * intense memory pressure but failed atomic allocations should be easier
>>> + * to recover from than an OOM.
>>> + */
>>> +static void unreserve_highatomic_pageblock(const struct alloc_context *ac)
>>> +{
>>> + struct zonelist *zonelist = ac->zonelist;
>>> + unsigned long flags;
>>> + struct zoneref *z;
>>> + struct zone *zone;
>>> + struct page *page;
>>> + int order;
>>> +
>>> + for_each_zone_zonelist_nodemask(zone, z, zonelist, ac->high_zoneidx,
>>> + ac->nodemask) {
>>> + /* Preserve at least one pageblock */
>>> + if (zone->nr_reserved_highatomic <= pageblock_nr_pages)
>>> + continue;
>>> +
>>> + spin_lock_irqsave(&zone->lock, flags);
>>> + for (order = 0; order < MAX_ORDER; order++) {
>>> + struct free_area *area = &(zone->free_area[order]);
>>> +
>>> + if (list_empty(&area->free_list[MIGRATE_HIGHATOMIC]))
>>> + continue;
>>> +
>>> + page = list_entry(area->free_list[MIGRATE_HIGHATOMIC].next,
>>> + struct page, lru);
>>> +
>>> + zone->nr_reserved_highatomic -= pageblock_nr_pages;
>>
>> So if the race happened here, zone->nr_reserved_highatomic underflows?
>>
>
> It shouldn't. If there are entries on the MIGRATE_HIGHATOMIC list then
> it should be accounted for in nr_reserved_highatomic. However, I see your
> point as a spill from per-cpu lists has caused us problems in the past.
>
> ---8<---
> From: Mel Gorman <mgorman@techsingularity.net>
> Subject: [PATCH] mm, page_alloc: Reserve pageblocks for high-order atomic
> allocations on demand -fix
>
> nr_reserved_highatomic is checked outside the zone lock so there is a race
> whereby the reserve is larger than the limit allows. This patch rechecks
> the count under the zone lock.
>
> During unreserving, there is a possibility we could underflow if there
> ever was a race between per-cpu drains, reserve and unreserving. This
> patch adds a comment about the potential race and protects against it.
>
> These are two fixes to the mmotm patch
> mm-page_alloc-reserve-pageblocks-for-high-order-atomic-allocations-on-demand.patch .
> They are not separate patches and they should all be folded together.
>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Ack.
> ---
> mm/page_alloc.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 811d6fc4ad5d..b1892dc51b55 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1633,9 +1633,13 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
> if (zone->nr_reserved_highatomic >= max_managed)
> return;
>
> - /* Yoink! */
> spin_lock_irqsave(&zone->lock, flags);
>
> + /* Recheck the nr_reserved_highatomic limit under the lock */
> + if (zone->nr_reserved_highatomic >= max_managed)
> + goto out_unlock;
> +
> + /* Yoink! */
> mt = get_pageblock_migratetype(page);
> if (mt != MIGRATE_HIGHATOMIC &&
> !is_migrate_isolate(mt) && !is_migrate_cma(mt)) {
> @@ -1643,6 +1647,8 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
> set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
> move_freepages_block(zone, page, MIGRATE_HIGHATOMIC);
> }
> +
> +out_unlock:
> spin_unlock_irqrestore(&zone->lock, flags);
> }
>
> @@ -1677,7 +1683,14 @@ static void unreserve_highatomic_pageblock(const struct alloc_context *ac)
> page = list_entry(area->free_list[MIGRATE_HIGHATOMIC].next,
> struct page, lru);
>
> - zone->nr_reserved_highatomic -= pageblock_nr_pages;
> + /*
> + * It should never happen but changes to locking could
> + * inadvertently allow a per-cpu drain to add pages
> + * to MIGRATE_HIGHATOMIC while unreserving so be safe
> + * and watch for underflows.
> + */
> + zone->nr_reserved_highatomic -= min(pageblock_nr_pages,
> + zone->nr_reserved_highatomic);
>
> /*
> * Convert to ac->migratetype and avoid the normal
>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Mel Gorman <mgorman@techsingularity.net>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Rik van Riel <riel@redhat.com>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Michal Hocko <mhocko@kernel.org>, Linux-MM <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand
Date: Wed, 30 Sep 2015 16:02:19 +0200 [thread overview]
Message-ID: <560BEB6B.7050004@suse.cz> (raw)
In-Reply-To: <20150930082725.GL3068@techsingularity.net>
On 09/30/2015 10:27 AM, Mel Gorman wrote:
> On Tue, Sep 29, 2015 at 02:01:41PM -0700, Andrew Morton wrote:
>>> ...
>>>
>>> +/*
>>> + * Reserve a pageblock for exclusive use of high-order atomic allocations if
>>> + * there are no empty page blocks that contain a page with a suitable order
>>> + */
>>> +static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
>>> + unsigned int alloc_order)
>>> +{
>>> + int mt;
>>> + unsigned long max_managed, flags;
>>> +
>>> + /*
>>> + * Limit the number reserved to 1 pageblock or roughly 1% of a zone.
>>> + * Check is race-prone but harmless.
>>> + */
>>> + max_managed = (zone->managed_pages / 100) + pageblock_nr_pages;
>>> + if (zone->nr_reserved_highatomic >= max_managed)
>>> + return;
>>> +
>>> + /* Yoink! */
>>> + spin_lock_irqsave(&zone->lock, flags);
>>> +
>>> + mt = get_pageblock_migratetype(page);
>>> + if (mt != MIGRATE_HIGHATOMIC &&
>>> + !is_migrate_isolate(mt) && !is_migrate_cma(mt)) {
>>
>> Do the above checks really need to be inside zone->lock? I don't think
>> get_pageblock_migratetype() needs zone->lock? (Actually I suspect it
>> does, but we don't...)
>>
>
> The get_pageblock_migratetype does not require zone->lock but it's race-prone
> without it and there have been cases (CMA, isolation) that cared. In this
> case, without the lock two parallel allocations may try to reserve the same
> block so we'd have to recheck the type under the lock to avoid corrupting
> nr_reserved_highatomic. As the move between free lists absolutely requires
> the zone->lock, it's best to just do the full operation under the lock.
>
>>> + zone->nr_reserved_highatomic += pageblock_nr_pages;
>>
>> And I don't think it would hurt to recheck
>> nr_reserved_highatomic>=max_managed after taking zone->lock, to plug
>> that race. We've had VM we-dont-care races in the past which ended up
>> causing problems in rare circumstances...
>>
>
> That makes sense, patch is below.
>
>>> + set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
>>> + move_freepages_block(zone, page, MIGRATE_HIGHATOMIC);
>>> + }
>>> + spin_unlock_irqrestore(&zone->lock, flags);
>>> +}
>>> +
>>> +/*
>>> + * Used when an allocation is about to fail under memory pressure. This
>>> + * potentially hurts the reliability of high-order allocations when under
>>> + * intense memory pressure but failed atomic allocations should be easier
>>> + * to recover from than an OOM.
>>> + */
>>> +static void unreserve_highatomic_pageblock(const struct alloc_context *ac)
>>> +{
>>> + struct zonelist *zonelist = ac->zonelist;
>>> + unsigned long flags;
>>> + struct zoneref *z;
>>> + struct zone *zone;
>>> + struct page *page;
>>> + int order;
>>> +
>>> + for_each_zone_zonelist_nodemask(zone, z, zonelist, ac->high_zoneidx,
>>> + ac->nodemask) {
>>> + /* Preserve at least one pageblock */
>>> + if (zone->nr_reserved_highatomic <= pageblock_nr_pages)
>>> + continue;
>>> +
>>> + spin_lock_irqsave(&zone->lock, flags);
>>> + for (order = 0; order < MAX_ORDER; order++) {
>>> + struct free_area *area = &(zone->free_area[order]);
>>> +
>>> + if (list_empty(&area->free_list[MIGRATE_HIGHATOMIC]))
>>> + continue;
>>> +
>>> + page = list_entry(area->free_list[MIGRATE_HIGHATOMIC].next,
>>> + struct page, lru);
>>> +
>>> + zone->nr_reserved_highatomic -= pageblock_nr_pages;
>>
>> So if the race happened here, zone->nr_reserved_highatomic underflows?
>>
>
> It shouldn't. If there are entries on the MIGRATE_HIGHATOMIC list then
> it should be accounted for in nr_reserved_highatomic. However, I see your
> point as a spill from per-cpu lists has caused us problems in the past.
>
> ---8<---
> From: Mel Gorman <mgorman@techsingularity.net>
> Subject: [PATCH] mm, page_alloc: Reserve pageblocks for high-order atomic
> allocations on demand -fix
>
> nr_reserved_highatomic is checked outside the zone lock so there is a race
> whereby the reserve is larger than the limit allows. This patch rechecks
> the count under the zone lock.
>
> During unreserving, there is a possibility we could underflow if there
> ever was a race between per-cpu drains, reserve and unreserving. This
> patch adds a comment about the potential race and protects against it.
>
> These are two fixes to the mmotm patch
> mm-page_alloc-reserve-pageblocks-for-high-order-atomic-allocations-on-demand.patch .
> They are not separate patches and they should all be folded together.
>
> Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Ack.
> ---
> mm/page_alloc.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 811d6fc4ad5d..b1892dc51b55 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1633,9 +1633,13 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
> if (zone->nr_reserved_highatomic >= max_managed)
> return;
>
> - /* Yoink! */
> spin_lock_irqsave(&zone->lock, flags);
>
> + /* Recheck the nr_reserved_highatomic limit under the lock */
> + if (zone->nr_reserved_highatomic >= max_managed)
> + goto out_unlock;
> +
> + /* Yoink! */
> mt = get_pageblock_migratetype(page);
> if (mt != MIGRATE_HIGHATOMIC &&
> !is_migrate_isolate(mt) && !is_migrate_cma(mt)) {
> @@ -1643,6 +1647,8 @@ static void reserve_highatomic_pageblock(struct page *page, struct zone *zone,
> set_pageblock_migratetype(page, MIGRATE_HIGHATOMIC);
> move_freepages_block(zone, page, MIGRATE_HIGHATOMIC);
> }
> +
> +out_unlock:
> spin_unlock_irqrestore(&zone->lock, flags);
> }
>
> @@ -1677,7 +1683,14 @@ static void unreserve_highatomic_pageblock(const struct alloc_context *ac)
> page = list_entry(area->free_list[MIGRATE_HIGHATOMIC].next,
> struct page, lru);
>
> - zone->nr_reserved_highatomic -= pageblock_nr_pages;
> + /*
> + * It should never happen but changes to locking could
> + * inadvertently allow a per-cpu drain to add pages
> + * to MIGRATE_HIGHATOMIC while unreserving so be safe
> + * and watch for underflows.
> + */
> + zone->nr_reserved_highatomic -= min(pageblock_nr_pages,
> + zone->nr_reserved_highatomic);
>
> /*
> * Convert to ac->migratetype and avoid the normal
>
next prev parent reply other threads:[~2015-09-30 14:02 UTC|newest]
Thread overview: 122+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-21 10:52 [PATCH 00/10] Remove zonelist cache and high-order watermark checking v4 Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-21 10:52 ` [PATCH 01/10] mm, page_alloc: Remove unnecessary parameter from zone_watermark_ok_safe Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-24 20:01 ` Johannes Weiner
2015-09-24 20:01 ` Johannes Weiner
2015-09-21 10:52 ` [PATCH 02/10] mm, page_alloc: Remove unnecessary recalculations for dirty zone balancing Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-24 20:05 ` Johannes Weiner
2015-09-24 20:05 ` Johannes Weiner
2015-09-21 10:52 ` [PATCH 03/10] mm, page_alloc: Remove unnecessary taking of a seqlock when cpusets are disabled Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-24 20:06 ` Johannes Weiner
2015-09-24 20:06 ` Johannes Weiner
2015-09-30 22:22 ` David Rientjes
2015-09-30 22:22 ` David Rientjes
2015-10-01 7:35 ` Vlastimil Babka
2015-10-01 7:35 ` Vlastimil Babka
2015-09-21 10:52 ` [PATCH 04/10] mm, page_alloc: Use masks and shifts when converting GFP flags to migrate types Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-24 20:34 ` Johannes Weiner
2015-09-24 20:34 ` Johannes Weiner
2015-09-25 12:50 ` Mel Gorman
2015-09-25 12:50 ` Mel Gorman
2015-09-25 13:56 ` Johannes Weiner
2015-09-25 13:56 ` Johannes Weiner
2015-09-21 10:52 ` [PATCH 05/10] mm, page_alloc: Distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-24 13:51 ` Michal Hocko
2015-09-24 13:51 ` Michal Hocko
2015-09-24 20:55 ` Johannes Weiner
2015-09-24 20:55 ` Johannes Weiner
2015-09-25 12:51 ` Mel Gorman
2015-09-25 12:51 ` Mel Gorman
2015-09-25 19:01 ` Johannes Weiner
2015-09-25 19:01 ` Johannes Weiner
2015-09-29 13:35 ` Mel Gorman
2015-09-29 13:35 ` Mel Gorman
2015-09-30 12:26 ` Vlastimil Babka
2015-09-30 12:26 ` Vlastimil Babka
2015-09-30 13:17 ` Mel Gorman
2015-09-30 13:17 ` Mel Gorman
2015-10-01 3:04 ` Drokin, Oleg
2015-10-01 3:04 ` Drokin, Oleg
2015-10-02 12:30 ` Mel Gorman
2015-10-02 12:30 ` Mel Gorman
2015-09-21 10:52 ` [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-25 19:03 ` Johannes Weiner
2015-09-25 19:03 ` Johannes Weiner
2015-09-28 23:55 ` Andrew Morton
2015-09-28 23:55 ` Andrew Morton
2015-09-29 13:37 ` Mel Gorman
2015-09-29 13:37 ` Mel Gorman
2015-10-01 8:39 ` Vlastimil Babka
2015-10-01 8:39 ` Vlastimil Babka
2015-10-02 13:03 ` [PATCH] mm: page_alloc: Hide some GFP internals and document the bits and flag combinations -fix Mel Gorman
2015-10-02 13:03 ` Mel Gorman
2015-10-01 14:06 ` [PATCH 06/10] mm, page_alloc: Rename __GFP_WAIT to __GFP_RECLAIM Michal Hocko
2015-10-01 14:06 ` Michal Hocko
2015-09-30 22:25 ` David Rientjes
2015-09-30 22:25 ` David Rientjes
2015-09-21 10:52 ` [PATCH 07/10] mm, page_alloc: Delete the zonelist_cache Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-25 19:09 ` Johannes Weiner
2015-09-25 19:09 ` Johannes Weiner
2015-09-21 10:52 ` [PATCH 08/10] mm, page_alloc: Remove MIGRATE_RESERVE Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-21 10:52 ` [PATCH 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand Mel Gorman
2015-09-21 10:52 ` Mel Gorman
2015-09-24 13:50 ` Michal Hocko
2015-09-24 13:50 ` Michal Hocko
2015-09-25 19:22 ` Johannes Weiner
2015-09-25 19:22 ` Johannes Weiner
2015-09-29 21:01 ` Andrew Morton
2015-09-29 21:01 ` Andrew Morton
2015-09-30 8:27 ` Mel Gorman
2015-09-30 8:27 ` Mel Gorman
2015-09-30 14:02 ` Vlastimil Babka [this message]
2015-09-30 14:02 ` Vlastimil Babka
2015-09-21 12:03 ` [PATCH 10/10] mm, page_alloc: Only enforce watermarks for order-0 allocations Mel Gorman
2015-09-21 12:03 ` Mel Gorman
2015-09-25 19:32 ` Johannes Weiner
2015-09-25 19:32 ` Johannes Weiner
2015-09-29 21:05 ` Andrew Morton
2015-09-29 21:05 ` Andrew Morton
2015-09-30 8:46 ` Mel Gorman
2015-09-30 8:46 ` Mel Gorman
2015-09-30 14:17 ` Vlastimil Babka
2015-09-30 14:17 ` Vlastimil Babka
2015-09-30 15:12 ` Mel Gorman
2015-09-30 15:12 ` Mel Gorman
2015-09-30 20:37 ` Andrew Morton
2015-09-30 20:37 ` Andrew Morton
2015-09-30 14:11 ` Vlastimil Babka
2015-09-30 14:11 ` Vlastimil Babka
-- strict thread matches above, loose matches on Subject: below --
2015-08-12 10:45 [PATCH 00/10] Remove zonelist cache and high-order watermark checking v2 Mel Gorman
2015-08-12 10:45 ` [PATCH 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand Mel Gorman
2015-08-12 10:45 ` Mel Gorman
2015-07-20 8:00 [RFC PATCH 00/10] Remove zonelist cache and high-order watermark checking Mel Gorman
2015-07-20 8:00 ` [PATCH 09/10] mm, page_alloc: Reserve pageblocks for high-order atomic allocations on demand Mel Gorman
2015-07-20 8:00 ` Mel Gorman
2015-07-29 11:35 ` Vlastimil Babka
2015-07-29 11:35 ` Vlastimil Babka
2015-07-29 12:53 ` Mel Gorman
2015-07-29 12:53 ` Mel Gorman
2015-07-31 8:28 ` Vlastimil Babka
2015-07-31 8:28 ` Vlastimil Babka
2015-07-31 8:43 ` Mel Gorman
2015-07-31 8:43 ` Mel Gorman
2015-07-31 5:54 ` Joonsoo Kim
2015-07-31 5:54 ` Joonsoo Kim
2015-07-31 7:11 ` Mel Gorman
2015-07-31 7:11 ` Mel Gorman
2015-07-31 7:25 ` Vlastimil Babka
2015-07-31 7:25 ` Vlastimil Babka
2015-07-31 8:22 ` Mel Gorman
2015-07-31 8:22 ` Mel Gorman
2015-07-31 8:30 ` Joonsoo Kim
2015-07-31 8:30 ` Joonsoo Kim
2015-07-31 8:26 ` Joonsoo Kim
2015-07-31 8:26 ` Joonsoo Kim
2015-07-31 8:41 ` Mel Gorman
2015-07-31 8:41 ` Mel Gorman
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=560BEB6B.7050004@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@kernel.org \
--cc=riel@redhat.com \
--cc=rientjes@google.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.