All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 10/11] Direct compact when a high-order allocation fails
Date: Wed, 24 Mar 2010 13:48:16 -0700	[thread overview]
Message-ID: <20100324134816.529778bd.akpm@linux-foundation.org> (raw)
In-Reply-To: <1269347146-7461-11-git-send-email-mel@csn.ul.ie>

On Tue, 23 Mar 2010 12:25:45 +0000
Mel Gorman <mel@csn.ul.ie> wrote:

> Ordinarily when a high-order allocation fails, direct reclaim is entered to
> free pages to satisfy the allocation.  With this patch, it is determined if
> an allocation failed due to external fragmentation instead of low memory
> and if so, the calling process will compact until a suitable page is
> freed. Compaction by moving pages in memory is considerably cheaper than
> paging out to disk and works where there are locked pages or no swap. If
> compaction fails to free a page of a suitable size, then reclaim will
> still occur.
> 
> Direct compaction returns as soon as possible. As each block is compacted,
> it is checked if a suitable page has been freed and if so, it returns.
> 
>
> ...
>
> +static inline unsigned long compact_zone_order(struct zone *zone,
> +						int order, gfp_t gfp_mask)

Suggest that you re-review all the manual inlining in the patchset. 
It's rarely needed and often incorrect.

> +{
> +	struct compact_control cc = {
> +		.nr_freepages = 0,
> +		.nr_migratepages = 0,
> +		.order = order,
> +		.migratetype = allocflags_to_migratetype(gfp_mask),
> +		.zone = zone,
> +	};
> +	INIT_LIST_HEAD(&cc.freepages);
> +	INIT_LIST_HEAD(&cc.migratepages);
> +
> +	return compact_zone(zone, &cc);
> +}
> +
> +/**
> + * try_to_compact_pages - Direct compact to satisfy a high-order allocation
> + * @zonelist: The zonelist used for the current allocation
> + * @order: The order of the current allocation
> + * @gfp_mask: The GFP mask of the current allocation
> + * @nodemask: The allowed nodes to allocate from
> + *
> + * This is the main entry point for direct page compaction.
> + */
> +unsigned long try_to_compact_pages(struct zonelist *zonelist,
> +			int order, gfp_t gfp_mask, nodemask_t *nodemask)
> +{
> +	enum zone_type high_zoneidx = gfp_zone(gfp_mask);
> +	int may_enter_fs = gfp_mask & __GFP_FS;
> +	int may_perform_io = gfp_mask & __GFP_IO;
> +	unsigned long watermark;
> +	struct zoneref *z;
> +	struct zone *zone;
> +	int rc = COMPACT_INCOMPLETE;
> +
> +	/* Check whether it is worth even starting compaction */
> +	if (order == 0 || !may_enter_fs || !may_perform_io)
> +		return rc;

hm, that was sad.  All those darn wireless drivers doing their
high-order GFP_ATOMIC allocations cannot be saved?

> +	/*
> +	 * We will not stall if the necessary conditions are not met for
> +	 * migration but direct reclaim seems to account stalls similarly
> +	 */
> +	count_vm_event(COMPACTSTALL);
> +
> +	/* Compact each zone in the list */
> +	for_each_zone_zonelist_nodemask(zone, z, zonelist, high_zoneidx,
> +								nodemask) {

Will all of this code play nicely with memory hotplug?

> +		int fragindex;
> +		int status;
> +
> +		/*
> +		 * Watermarks for order-0 must be met for compaction. Note
> +		 * the 2UL. This is because during migration, copies of
> +		 * pages need to be allocated and for a short time, the
> +		 * footprint is higher
> +		 */
> +		watermark = low_wmark_pages(zone) + (2UL << order);
> +		if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
> +			continue;
> +
> +		/*
> +		 * fragmentation index determines if allocation failures are
> +		 * due to low memory or external fragmentation
> +		 *
> +		 * index of -1 implies allocations might succeed depending
> +		 * 	on watermarks
> +		 * index < 500 implies alloc failure is due to lack of memory
> +		 *
> +		 * XXX: The choice of 500 is arbitrary. Reinvestigate
> +		 *      appropriately to determine a sensible default.
> +		 *      and what it means when watermarks are also taken
> +		 *      into account. Consider making it a sysctl
> +		 */

Yes, best to make it a sysctl IMO.   It'll make optimisation far easier.
/proc/sys/vm/fragmentation_index_dont_you_dare_use_this_it_will_disappear_soon

> +		fragindex = fragmentation_index(zone, order);
> +		if (fragindex >= 0 && fragindex <= 500)
> +			continue;
> +
> +		if (fragindex == -1 && zone_watermark_ok(zone, order, watermark, 0, 0)) {
> +			rc = COMPACT_PARTIAL;
> +			break;
> +		}
> +
> +		status = compact_zone_order(zone, order, gfp_mask);
> +		rc = max(status, rc);
> +
> +		if (zone_watermark_ok(zone, order, watermark, 0, 0))
> +			break;
> +	}
> +
> +	return rc;
> +}
>
> ...
>
> @@ -1765,6 +1766,31 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
>  
>  	cond_resched();
>  
> +	/* Try memory compaction for high-order allocations before reclaim */
> +	if (order) {
> +		*did_some_progress = try_to_compact_pages(zonelist,
> +						order, gfp_mask, nodemask);
> +		if (*did_some_progress != COMPACT_INCOMPLETE) {
> +			page = get_page_from_freelist(gfp_mask, nodemask,
> +					order, zonelist, high_zoneidx,
> +					alloc_flags, preferred_zone,
> +					migratetype);
> +			if (page) {
> +				__count_vm_event(COMPACTSUCCESS);
> +				return page;
> +			}
> +
> +			/*
> +			 * It's bad if compaction run occurs and fails.
> +			 * The most likely reason is that pages exist,
> +			 * but not enough to satisfy watermarks.
> +			 */
> +			count_vm_event(COMPACTFAIL);

This counter will get incremented if !__GFP_FS or !__GFP_IO.  Seems
wrong.

> +			cond_resched();
> +		}
> +	}
> +


WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrea Arcangeli <aarcange@redhat.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Adam Litke <agl@us.ibm.com>, Avi Kivity <avi@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Minchan Kim <minchan.kim@gmail.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 10/11] Direct compact when a high-order allocation fails
Date: Wed, 24 Mar 2010 13:48:16 -0700	[thread overview]
Message-ID: <20100324134816.529778bd.akpm@linux-foundation.org> (raw)
In-Reply-To: <1269347146-7461-11-git-send-email-mel@csn.ul.ie>

On Tue, 23 Mar 2010 12:25:45 +0000
Mel Gorman <mel@csn.ul.ie> wrote:

> Ordinarily when a high-order allocation fails, direct reclaim is entered to
> free pages to satisfy the allocation.  With this patch, it is determined if
> an allocation failed due to external fragmentation instead of low memory
> and if so, the calling process will compact until a suitable page is
> freed. Compaction by moving pages in memory is considerably cheaper than
> paging out to disk and works where there are locked pages or no swap. If
> compaction fails to free a page of a suitable size, then reclaim will
> still occur.
> 
> Direct compaction returns as soon as possible. As each block is compacted,
> it is checked if a suitable page has been freed and if so, it returns.
> 
>
> ...
>
> +static inline unsigned long compact_zone_order(struct zone *zone,
> +						int order, gfp_t gfp_mask)

Suggest that you re-review all the manual inlining in the patchset. 
It's rarely needed and often incorrect.

> +{
> +	struct compact_control cc = {
> +		.nr_freepages = 0,
> +		.nr_migratepages = 0,
> +		.order = order,
> +		.migratetype = allocflags_to_migratetype(gfp_mask),
> +		.zone = zone,
> +	};
> +	INIT_LIST_HEAD(&cc.freepages);
> +	INIT_LIST_HEAD(&cc.migratepages);
> +
> +	return compact_zone(zone, &cc);
> +}
> +
> +/**
> + * try_to_compact_pages - Direct compact to satisfy a high-order allocation
> + * @zonelist: The zonelist used for the current allocation
> + * @order: The order of the current allocation
> + * @gfp_mask: The GFP mask of the current allocation
> + * @nodemask: The allowed nodes to allocate from
> + *
> + * This is the main entry point for direct page compaction.
> + */
> +unsigned long try_to_compact_pages(struct zonelist *zonelist,
> +			int order, gfp_t gfp_mask, nodemask_t *nodemask)
> +{
> +	enum zone_type high_zoneidx = gfp_zone(gfp_mask);
> +	int may_enter_fs = gfp_mask & __GFP_FS;
> +	int may_perform_io = gfp_mask & __GFP_IO;
> +	unsigned long watermark;
> +	struct zoneref *z;
> +	struct zone *zone;
> +	int rc = COMPACT_INCOMPLETE;
> +
> +	/* Check whether it is worth even starting compaction */
> +	if (order == 0 || !may_enter_fs || !may_perform_io)
> +		return rc;

hm, that was sad.  All those darn wireless drivers doing their
high-order GFP_ATOMIC allocations cannot be saved?

> +	/*
> +	 * We will not stall if the necessary conditions are not met for
> +	 * migration but direct reclaim seems to account stalls similarly
> +	 */
> +	count_vm_event(COMPACTSTALL);
> +
> +	/* Compact each zone in the list */
> +	for_each_zone_zonelist_nodemask(zone, z, zonelist, high_zoneidx,
> +								nodemask) {

Will all of this code play nicely with memory hotplug?

> +		int fragindex;
> +		int status;
> +
> +		/*
> +		 * Watermarks for order-0 must be met for compaction. Note
> +		 * the 2UL. This is because during migration, copies of
> +		 * pages need to be allocated and for a short time, the
> +		 * footprint is higher
> +		 */
> +		watermark = low_wmark_pages(zone) + (2UL << order);
> +		if (!zone_watermark_ok(zone, 0, watermark, 0, 0))
> +			continue;
> +
> +		/*
> +		 * fragmentation index determines if allocation failures are
> +		 * due to low memory or external fragmentation
> +		 *
> +		 * index of -1 implies allocations might succeed depending
> +		 * 	on watermarks
> +		 * index < 500 implies alloc failure is due to lack of memory
> +		 *
> +		 * XXX: The choice of 500 is arbitrary. Reinvestigate
> +		 *      appropriately to determine a sensible default.
> +		 *      and what it means when watermarks are also taken
> +		 *      into account. Consider making it a sysctl
> +		 */

Yes, best to make it a sysctl IMO.   It'll make optimisation far easier.
/proc/sys/vm/fragmentation_index_dont_you_dare_use_this_it_will_disappear_soon

> +		fragindex = fragmentation_index(zone, order);
> +		if (fragindex >= 0 && fragindex <= 500)
> +			continue;
> +
> +		if (fragindex == -1 && zone_watermark_ok(zone, order, watermark, 0, 0)) {
> +			rc = COMPACT_PARTIAL;
> +			break;
> +		}
> +
> +		status = compact_zone_order(zone, order, gfp_mask);
> +		rc = max(status, rc);
> +
> +		if (zone_watermark_ok(zone, order, watermark, 0, 0))
> +			break;
> +	}
> +
> +	return rc;
> +}
>
> ...
>
> @@ -1765,6 +1766,31 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
>  
>  	cond_resched();
>  
> +	/* Try memory compaction for high-order allocations before reclaim */
> +	if (order) {
> +		*did_some_progress = try_to_compact_pages(zonelist,
> +						order, gfp_mask, nodemask);
> +		if (*did_some_progress != COMPACT_INCOMPLETE) {
> +			page = get_page_from_freelist(gfp_mask, nodemask,
> +					order, zonelist, high_zoneidx,
> +					alloc_flags, preferred_zone,
> +					migratetype);
> +			if (page) {
> +				__count_vm_event(COMPACTSUCCESS);
> +				return page;
> +			}
> +
> +			/*
> +			 * It's bad if compaction run occurs and fails.
> +			 * The most likely reason is that pages exist,
> +			 * but not enough to satisfy watermarks.
> +			 */
> +			count_vm_event(COMPACTFAIL);

This counter will get incremented if !__GFP_FS or !__GFP_IO.  Seems
wrong.

> +			cond_resched();
> +		}
> +	}
> +

--
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>

  parent reply	other threads:[~2010-03-24 20:49 UTC|newest]

Thread overview: 172+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 12:25 [PATCH 0/11] Memory Compaction v5 Mel Gorman
2010-03-23 12:25 ` Mel Gorman
2010-03-23 12:25 ` [PATCH 01/11] mm,migration: Take a reference to the anon_vma before migrating Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 12:25 ` [PATCH 02/11] mm,migration: Do not try to migrate unmapped anonymous pages Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 17:22   ` Christoph Lameter
2010-03-23 17:22     ` Christoph Lameter
2010-03-23 18:04     ` Mel Gorman
2010-03-23 18:04       ` Mel Gorman
2010-03-23 12:25 ` [PATCH 03/11] mm: Share the anon_vma ref counts between KSM and page migration Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 17:25   ` Christoph Lameter
2010-03-23 17:25     ` Christoph Lameter
2010-03-23 23:55   ` KAMEZAWA Hiroyuki
2010-03-23 23:55     ` KAMEZAWA Hiroyuki
2010-03-23 12:25 ` [PATCH 04/11] Allow CONFIG_MIGRATION to be set without CONFIG_NUMA or memory hot-remove Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 12:25 ` [PATCH 05/11] Export unusable free space index via /proc/unusable_index Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 17:31   ` Christoph Lameter
2010-03-23 17:31     ` Christoph Lameter
2010-03-23 18:14     ` Mel Gorman
2010-03-23 18:14       ` Mel Gorman
2010-03-24  0:03   ` KAMEZAWA Hiroyuki
2010-03-24  0:03     ` KAMEZAWA Hiroyuki
2010-03-24  0:16     ` Minchan Kim
2010-03-24  0:16       ` Minchan Kim
2010-03-24  0:13       ` KAMEZAWA Hiroyuki
2010-03-24  0:13         ` KAMEZAWA Hiroyuki
2010-03-24 10:25     ` Mel Gorman
2010-03-24 10:25       ` Mel Gorman
2010-03-23 12:25 ` [PATCH 06/11] Export fragmentation index via /proc/extfrag_index Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 17:37   ` Christoph Lameter
2010-03-23 17:37     ` Christoph Lameter
2010-03-23 12:25 ` [PATCH 07/11] Memory compaction core Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 17:56   ` Christoph Lameter
2010-03-23 17:56     ` Christoph Lameter
2010-03-23 18:15     ` Mel Gorman
2010-03-23 18:15       ` Mel Gorman
2010-03-23 18:33       ` Christoph Lameter
2010-03-23 18:33         ` Christoph Lameter
2010-03-23 18:58         ` Mel Gorman
2010-03-23 18:58           ` Mel Gorman
2010-03-23 19:20           ` Christoph Lameter
2010-03-23 19:20             ` Christoph Lameter
2010-03-24  1:03   ` KAMEZAWA Hiroyuki
2010-03-24  1:03     ` KAMEZAWA Hiroyuki
2010-03-24  1:47     ` Minchan Kim
2010-03-24  1:47       ` Minchan Kim
2010-03-24  1:53       ` KAMEZAWA Hiroyuki
2010-03-24  1:53         ` KAMEZAWA Hiroyuki
2010-03-24  2:10         ` Minchan Kim
2010-03-24  2:10           ` Minchan Kim
2010-03-24 10:57           ` Mel Gorman
2010-03-24 10:57             ` Mel Gorman
2010-03-24 20:33   ` Andrew Morton
2010-03-24 20:33     ` Andrew Morton
2010-03-24 20:59     ` Jonathan Corbet
2010-03-24 20:59       ` Jonathan Corbet
2010-03-24 21:14       ` Andrew Morton
2010-03-24 21:14         ` Andrew Morton
2010-03-24 21:19         ` Christoph Lameter
2010-03-24 21:19           ` Christoph Lameter
2010-03-24 21:19       ` Andrea Arcangeli
2010-03-24 21:19         ` Andrea Arcangeli
2010-03-24 21:28         ` Jonathan Corbet
2010-03-24 21:28           ` Jonathan Corbet
2010-03-24 21:47           ` Andrea Arcangeli
2010-03-24 21:47             ` Andrea Arcangeli
2010-03-24 21:54             ` Jonathan Corbet
2010-03-24 21:54               ` Jonathan Corbet
2010-03-24 22:06               ` Andrea Arcangeli
2010-03-24 22:06                 ` Andrea Arcangeli
2010-03-24 21:57             ` Andrea Arcangeli
2010-03-24 21:57               ` Andrea Arcangeli
2010-03-25  9:13     ` Mel Gorman
2010-03-25  9:13       ` Mel Gorman
2010-03-23 12:25 ` [PATCH 08/11] Add /proc trigger for memory compaction Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 18:25   ` Christoph Lameter
2010-03-23 18:25     ` Christoph Lameter
2010-03-23 18:32     ` Mel Gorman
2010-03-23 18:32       ` Mel Gorman
2010-03-24 20:33   ` Andrew Morton
2010-03-24 20:33     ` Andrew Morton
2010-03-26 10:46     ` Mel Gorman
2010-03-26 10:46       ` Mel Gorman
2010-03-23 12:25 ` [PATCH 09/11] Add /sys trigger for per-node " Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 18:27   ` Christoph Lameter
2010-03-23 18:27     ` Christoph Lameter
2010-03-23 22:45   ` Minchan Kim
2010-03-23 22:45     ` Minchan Kim
2010-03-24  0:19   ` KAMEZAWA Hiroyuki
2010-03-24  0:19     ` KAMEZAWA Hiroyuki
2010-03-23 12:25 ` [PATCH 10/11] Direct compact when a high-order allocation fails Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 23:10   ` Minchan Kim
2010-03-23 23:10     ` Minchan Kim
2010-03-24 11:11     ` Mel Gorman
2010-03-24 11:11       ` Mel Gorman
2010-03-24 11:59       ` Minchan Kim
2010-03-24 11:59         ` Minchan Kim
2010-03-24 12:06         ` Minchan Kim
2010-03-24 12:06           ` Minchan Kim
2010-03-24 12:10           ` Mel Gorman
2010-03-24 12:10             ` Mel Gorman
2010-03-24 12:09         ` Mel Gorman
2010-03-24 12:09           ` Mel Gorman
2010-03-24 12:25           ` Minchan Kim
2010-03-24 12:25             ` Minchan Kim
2010-03-24  1:19   ` KAMEZAWA Hiroyuki
2010-03-24  1:19     ` KAMEZAWA Hiroyuki
2010-03-24 11:40     ` Mel Gorman
2010-03-24 11:40       ` Mel Gorman
2010-03-25  0:30       ` KAMEZAWA Hiroyuki
2010-03-25  0:30         ` KAMEZAWA Hiroyuki
2010-03-25  9:48         ` Mel Gorman
2010-03-25  9:48           ` Mel Gorman
2010-03-25  9:50           ` KAMEZAWA Hiroyuki
2010-03-25  9:50             ` KAMEZAWA Hiroyuki
2010-03-25 10:16             ` Mel Gorman
2010-03-25 10:16               ` Mel Gorman
2010-03-26  1:03               ` KAMEZAWA Hiroyuki
2010-03-26  1:03                 ` KAMEZAWA Hiroyuki
2010-03-26  9:40                 ` Mel Gorman
2010-03-26  9:40                   ` Mel Gorman
2010-03-24 20:48   ` Andrew Morton [this message]
2010-03-24 20:48     ` Andrew Morton
2010-03-25  0:57     ` KAMEZAWA Hiroyuki
2010-03-25  0:57       ` KAMEZAWA Hiroyuki
2010-03-25 10:21     ` Mel Gorman
2010-03-25 10:21       ` Mel Gorman
2010-03-23 12:25 ` [PATCH 11/11] Do not compact within a preferred zone after a compaction failure Mel Gorman
2010-03-23 12:25   ` Mel Gorman
2010-03-23 18:31   ` Christoph Lameter
2010-03-23 18:31     ` Christoph Lameter
2010-03-23 18:39     ` Mel Gorman
2010-03-23 18:39       ` Mel Gorman
2010-03-23 19:27       ` Christoph Lameter
2010-03-23 19:27         ` Christoph Lameter
2010-03-24 10:37         ` Mel Gorman
2010-03-24 10:37           ` Mel Gorman
2010-03-24 19:54           ` Christoph Lameter
2010-03-24 19:54             ` Christoph Lameter
2010-03-24 20:53   ` Andrew Morton
2010-03-24 20:53     ` Andrew Morton
2010-03-25  9:40     ` Mel Gorman
2010-03-25  9:40       ` Mel Gorman
  -- strict thread matches above, loose matches on Subject: below --
2010-03-12 16:41 [PATCH 0/11] Memory Compaction v4 Mel Gorman
2010-03-12 16:41 ` [PATCH 10/11] Direct compact when a high-order allocation fails Mel Gorman
2010-03-12 16:41   ` Mel Gorman
2010-03-16  2:47   ` Minchan Kim
2010-03-16  2:47     ` Minchan Kim
2010-03-19  6:21   ` KOSAKI Motohiro
2010-03-19  6:21     ` KOSAKI Motohiro
2010-03-19  6:31     ` KOSAKI Motohiro
2010-03-19  6:31       ` KOSAKI Motohiro
2010-03-19 10:10       ` Mel Gorman
2010-03-19 10:10         ` Mel Gorman
2010-03-25 11:22         ` KOSAKI Motohiro
2010-03-25 11:22           ` KOSAKI Motohiro
2010-03-19 10:09     ` Mel Gorman
2010-03-19 10:09       ` Mel Gorman
2010-03-25 11:08       ` KOSAKI Motohiro
2010-03-25 11:08         ` KOSAKI Motohiro
2010-03-25 15:11         ` Mel Gorman
2010-03-25 15:11           ` Mel Gorman
2010-03-26  6:01           ` KOSAKI Motohiro
2010-03-26  6:01             ` KOSAKI Motohiro

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=20100324134816.529778bd.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=aarcange@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=avi@redhat.com \
    --cc=cl@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --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.