From: Vlastimil Babka <vbabka@suse.cz>
To: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: "David Rientjes" <rientjes@google.com>,
"Jörn Engel" <joern@purestorage.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Naoya Horiguchi" <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps
Date: Wed, 9 Sep 2015 17:12:08 +0200 [thread overview]
Message-ID: <55F04C48.7070105@suse.cz> (raw)
In-Reply-To: <1440059182-19798-2-git-send-email-n-horiguchi@ah.jp.nec.com>
On 08/20/2015 10:26 AM, Naoya Horiguchi wrote:
> Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> To solve this, this patch adds a new line for hugetlb usage like below:
>
> Size: 20480 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> HugetlbPages: 18432 kB
> Swap: 0 kB
> KernelPageSize: 2048 kB
> MMUPageSize: 2048 kB
> Locked: 0 kB
> VmFlags: rd wr mr mw me de ht
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Acked-by: Joern Engel <joern@logfs.org>
> Acked-by: David Rientjes <rientjes@google.com>
Sorry for coming late to this thread. It's a nice improvement, but I
find it somewhat illogical that the per-process stats (status) are more
detailed than the per-mapping stats (smaps) with respect to the size
breakdown. I would expect it to be the other way around. That would
simplify the per-process accounting (I realize this has been a hot topic
already), and allow those who really care to look at smaps.
I'm just not sure about the format in that case. In smaps, a line per
size would probably make more sense. Even in status, the extra
information in parentheses looks somewhat out of place. But of course,
adding shared/private breakdown as suggested would lead to an explosion
of number of lines in that case...
> ---
> v3 -> v4:
> - suspend Acked-by tag because v3->v4 change is not trivial
> - I stated in previous discussion that HugetlbPages line can contain page
> size info, but that's not necessary because we already have KernelPageSize
> info.
> - merged documentation update, where the current documentation doesn't mention
> AnonHugePages, so it's also added.
> ---
> Documentation/filesystems/proc.txt | 7 +++++--
> fs/proc/task_mmu.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git v4.2-rc4/Documentation/filesystems/proc.txt v4.2-rc4_patched/Documentation/filesystems/proc.txt
> index 6f7fafde0884..22e40211ef64 100644
> --- v4.2-rc4/Documentation/filesystems/proc.txt
> +++ v4.2-rc4_patched/Documentation/filesystems/proc.txt
> @@ -423,6 +423,8 @@ Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 892 kB
> Anonymous: 0 kB
> +AnonHugePages: 0 kB
> +HugetlbPages: 0 kB
> Swap: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> @@ -440,8 +442,9 @@ indicates the amount of memory currently marked as referenced or accessed.
> "Anonymous" shows the amount of memory that does not belong to any file. Even
> a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
> and a page is modified, the file page is replaced by a private anonymous copy.
> -"Swap" shows how much would-be-anonymous memory is also used, but out on
> -swap.
> +"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
> +"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
> +"Swap" shows how much would-be-anonymous memory is also used, but out on swap.
>
> "VmFlags" field deserves a separate description. This member represents the kernel
> flags associated with the particular virtual memory area in two letter encoded
> diff --git v4.2-rc4/fs/proc/task_mmu.c v4.2-rc4_patched/fs/proc/task_mmu.c
> index ca1e091881d4..2c37938b82ee 100644
> --- v4.2-rc4/fs/proc/task_mmu.c
> +++ v4.2-rc4_patched/fs/proc/task_mmu.c
> @@ -445,6 +445,7 @@ struct mem_size_stats {
> unsigned long anonymous;
> unsigned long anonymous_thp;
> unsigned long swap;
> + unsigned long hugetlb;
> u64 pss;
> };
>
> @@ -610,12 +611,38 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> seq_putc(m, '\n');
> }
>
> +#ifdef CONFIG_HUGETLB_PAGE
> +static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
> + unsigned long addr, unsigned long end,
> + struct mm_walk *walk)
> +{
> + struct mem_size_stats *mss = walk->private;
> + struct vm_area_struct *vma = walk->vma;
> + struct page *page = NULL;
> +
> + if (pte_present(*pte)) {
> + page = vm_normal_page(vma, addr, *pte);
> + } else if (is_swap_pte(*pte)) {
> + swp_entry_t swpent = pte_to_swp_entry(*pte);
> +
> + if (is_migration_entry(swpent))
> + page = migration_entry_to_page(swpent);
> + }
> + if (page)
> + mss->hugetlb += huge_page_size(hstate_vma(vma));
> + return 0;
> +}
> +#endif /* HUGETLB_PAGE */
> +
> static int show_smap(struct seq_file *m, void *v, int is_pid)
> {
> struct vm_area_struct *vma = v;
> struct mem_size_stats mss;
> struct mm_walk smaps_walk = {
> .pmd_entry = smaps_pte_range,
> +#ifdef CONFIG_HUGETLB_PAGE
> + .hugetlb_entry = smaps_hugetlb_range,
> +#endif
> .mm = vma->vm_mm,
> .private = &mss,
> };
> @@ -637,6 +664,7 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
> "Referenced: %8lu kB\n"
> "Anonymous: %8lu kB\n"
> "AnonHugePages: %8lu kB\n"
> + "HugetlbPages: %8lu kB\n"
> "Swap: %8lu kB\n"
> "KernelPageSize: %8lu kB\n"
> "MMUPageSize: %8lu kB\n"
> @@ -651,6 +679,7 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
> mss.referenced >> 10,
> mss.anonymous >> 10,
> mss.anonymous_thp >> 10,
> + mss.hugetlb >> 10,
> mss.swap >> 10,
> vma_kernel_pagesize(vma) >> 10,
> vma_mmu_pagesize(vma) >> 10,
>
--
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: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: "David Rientjes" <rientjes@google.com>,
"Jörn Engel" <joern@purestorage.com>,
"Mike Kravetz" <mike.kravetz@oracle.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Naoya Horiguchi" <nao.horiguchi@gmail.com>
Subject: Re: [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps
Date: Wed, 9 Sep 2015 17:12:08 +0200 [thread overview]
Message-ID: <55F04C48.7070105@suse.cz> (raw)
In-Reply-To: <1440059182-19798-2-git-send-email-n-horiguchi@ah.jp.nec.com>
On 08/20/2015 10:26 AM, Naoya Horiguchi wrote:
> Currently /proc/PID/smaps provides no usage info for vma(VM_HUGETLB), which
> is inconvenient when we want to know per-task or per-vma base hugetlb usage.
> To solve this, this patch adds a new line for hugetlb usage like below:
>
> Size: 20480 kB
> Rss: 0 kB
> Pss: 0 kB
> Shared_Clean: 0 kB
> Shared_Dirty: 0 kB
> Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 0 kB
> Anonymous: 0 kB
> AnonHugePages: 0 kB
> HugetlbPages: 18432 kB
> Swap: 0 kB
> KernelPageSize: 2048 kB
> MMUPageSize: 2048 kB
> Locked: 0 kB
> VmFlags: rd wr mr mw me de ht
>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Acked-by: Joern Engel <joern@logfs.org>
> Acked-by: David Rientjes <rientjes@google.com>
Sorry for coming late to this thread. It's a nice improvement, but I
find it somewhat illogical that the per-process stats (status) are more
detailed than the per-mapping stats (smaps) with respect to the size
breakdown. I would expect it to be the other way around. That would
simplify the per-process accounting (I realize this has been a hot topic
already), and allow those who really care to look at smaps.
I'm just not sure about the format in that case. In smaps, a line per
size would probably make more sense. Even in status, the extra
information in parentheses looks somewhat out of place. But of course,
adding shared/private breakdown as suggested would lead to an explosion
of number of lines in that case...
> ---
> v3 -> v4:
> - suspend Acked-by tag because v3->v4 change is not trivial
> - I stated in previous discussion that HugetlbPages line can contain page
> size info, but that's not necessary because we already have KernelPageSize
> info.
> - merged documentation update, where the current documentation doesn't mention
> AnonHugePages, so it's also added.
> ---
> Documentation/filesystems/proc.txt | 7 +++++--
> fs/proc/task_mmu.c | 29 +++++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git v4.2-rc4/Documentation/filesystems/proc.txt v4.2-rc4_patched/Documentation/filesystems/proc.txt
> index 6f7fafde0884..22e40211ef64 100644
> --- v4.2-rc4/Documentation/filesystems/proc.txt
> +++ v4.2-rc4_patched/Documentation/filesystems/proc.txt
> @@ -423,6 +423,8 @@ Private_Clean: 0 kB
> Private_Dirty: 0 kB
> Referenced: 892 kB
> Anonymous: 0 kB
> +AnonHugePages: 0 kB
> +HugetlbPages: 0 kB
> Swap: 0 kB
> KernelPageSize: 4 kB
> MMUPageSize: 4 kB
> @@ -440,8 +442,9 @@ indicates the amount of memory currently marked as referenced or accessed.
> "Anonymous" shows the amount of memory that does not belong to any file. Even
> a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
> and a page is modified, the file page is replaced by a private anonymous copy.
> -"Swap" shows how much would-be-anonymous memory is also used, but out on
> -swap.
> +"AnonHugePages" shows the ammount of memory backed by transparent hugepage.
> +"HugetlbPages" shows the ammount of memory backed by hugetlbfs page.
> +"Swap" shows how much would-be-anonymous memory is also used, but out on swap.
>
> "VmFlags" field deserves a separate description. This member represents the kernel
> flags associated with the particular virtual memory area in two letter encoded
> diff --git v4.2-rc4/fs/proc/task_mmu.c v4.2-rc4_patched/fs/proc/task_mmu.c
> index ca1e091881d4..2c37938b82ee 100644
> --- v4.2-rc4/fs/proc/task_mmu.c
> +++ v4.2-rc4_patched/fs/proc/task_mmu.c
> @@ -445,6 +445,7 @@ struct mem_size_stats {
> unsigned long anonymous;
> unsigned long anonymous_thp;
> unsigned long swap;
> + unsigned long hugetlb;
> u64 pss;
> };
>
> @@ -610,12 +611,38 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> seq_putc(m, '\n');
> }
>
> +#ifdef CONFIG_HUGETLB_PAGE
> +static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
> + unsigned long addr, unsigned long end,
> + struct mm_walk *walk)
> +{
> + struct mem_size_stats *mss = walk->private;
> + struct vm_area_struct *vma = walk->vma;
> + struct page *page = NULL;
> +
> + if (pte_present(*pte)) {
> + page = vm_normal_page(vma, addr, *pte);
> + } else if (is_swap_pte(*pte)) {
> + swp_entry_t swpent = pte_to_swp_entry(*pte);
> +
> + if (is_migration_entry(swpent))
> + page = migration_entry_to_page(swpent);
> + }
> + if (page)
> + mss->hugetlb += huge_page_size(hstate_vma(vma));
> + return 0;
> +}
> +#endif /* HUGETLB_PAGE */
> +
> static int show_smap(struct seq_file *m, void *v, int is_pid)
> {
> struct vm_area_struct *vma = v;
> struct mem_size_stats mss;
> struct mm_walk smaps_walk = {
> .pmd_entry = smaps_pte_range,
> +#ifdef CONFIG_HUGETLB_PAGE
> + .hugetlb_entry = smaps_hugetlb_range,
> +#endif
> .mm = vma->vm_mm,
> .private = &mss,
> };
> @@ -637,6 +664,7 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
> "Referenced: %8lu kB\n"
> "Anonymous: %8lu kB\n"
> "AnonHugePages: %8lu kB\n"
> + "HugetlbPages: %8lu kB\n"
> "Swap: %8lu kB\n"
> "KernelPageSize: %8lu kB\n"
> "MMUPageSize: %8lu kB\n"
> @@ -651,6 +679,7 @@ static int show_smap(struct seq_file *m, void *v, int is_pid)
> mss.referenced >> 10,
> mss.anonymous >> 10,
> mss.anonymous_thp >> 10,
> + mss.hugetlb >> 10,
> mss.swap >> 10,
> vma_kernel_pagesize(vma) >> 10,
> vma_mmu_pagesize(vma) >> 10,
>
next prev parent reply other threads:[~2015-09-09 15:12 UTC|newest]
Thread overview: 142+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 23:26 hugetlb pages not accounted for in rss Mike Kravetz
2015-07-27 23:26 ` Mike Kravetz
2015-07-28 18:32 ` Jörn Engel
2015-07-28 18:32 ` Jörn Engel
2015-07-28 21:15 ` Mike Kravetz
2015-07-28 21:15 ` Mike Kravetz
2015-07-28 22:15 ` David Rientjes
2015-07-28 22:15 ` David Rientjes
2015-07-28 22:26 ` Jörn Engel
2015-07-28 22:26 ` Jörn Engel
2015-07-28 23:30 ` David Rientjes
2015-07-28 23:30 ` David Rientjes
2015-07-29 0:53 ` Jörn Engel
2015-07-29 0:53 ` Jörn Engel
2015-07-29 19:08 ` David Rientjes
2015-07-29 19:08 ` David Rientjes
2015-07-29 23:20 ` Mike Kravetz
2015-07-29 23:20 ` Mike Kravetz
2015-07-30 21:34 ` Jörn Engel
2015-07-30 21:34 ` Jörn Engel
2015-07-31 21:09 ` David Rientjes
2015-07-31 21:09 ` David Rientjes
2015-08-04 2:55 ` Naoya Horiguchi
2015-08-04 2:55 ` Naoya Horiguchi
2015-08-04 5:13 ` [PATCH] smaps: fill missing fields for vma(VM_HUGETLB) Naoya Horiguchi
2015-08-04 5:13 ` Naoya Horiguchi
2015-08-04 18:21 ` Jörn Engel
2015-08-04 18:21 ` Jörn Engel
2015-08-06 2:18 ` David Rientjes
2015-08-06 2:18 ` David Rientjes
2015-08-06 7:44 ` Naoya Horiguchi
2015-08-06 7:44 ` Naoya Horiguchi
2015-08-07 7:24 ` [PATCH v2 0/2] hugetlb: display per-process/per-vma usage Naoya Horiguchi
2015-08-07 7:24 ` Naoya Horiguchi
2015-08-07 7:24 ` [PATCH v2 1/2] smaps: fill missing fields for vma(VM_HUGETLB) Naoya Horiguchi
2015-08-07 7:24 ` Naoya Horiguchi
2015-08-07 22:50 ` Andrew Morton
2015-08-07 22:50 ` Andrew Morton
2015-08-11 0:37 ` David Rientjes
2015-08-11 0:37 ` David Rientjes
2015-08-11 23:32 ` Naoya Horiguchi
2015-08-11 23:32 ` Naoya Horiguchi
2015-08-11 23:48 ` David Rientjes
2015-08-11 23:48 ` David Rientjes
2015-08-07 7:24 ` [PATCH v2 2/2] mm: hugetlb: add VmHugetlbRSS: field in /proc/pid/status Naoya Horiguchi
2015-08-07 7:24 ` Naoya Horiguchi
2015-08-07 22:55 ` Andrew Morton
2015-08-07 22:55 ` Andrew Morton
2015-08-10 0:47 ` Naoya Horiguchi
2015-08-10 0:47 ` Naoya Horiguchi
2015-08-10 0:47 ` [PATCH v3 1/3] smaps: fill missing fields for vma(VM_HUGETLB) Naoya Horiguchi
2015-08-10 0:47 ` Naoya Horiguchi
2015-08-10 0:47 ` [PATCH v3 3/3] Documentation/filesystems/proc.txt: document hugetlb RSS Naoya Horiguchi
2015-08-10 0:47 ` Naoya Horiguchi
2015-08-11 0:44 ` David Rientjes
2015-08-11 0:44 ` David Rientjes
2015-08-12 0:03 ` Naoya Horiguchi
2015-08-12 0:03 ` Naoya Horiguchi
2015-08-12 7:45 ` [PATCH v4 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps Naoya Horiguchi
2015-08-12 7:45 ` Naoya Horiguchi
2015-08-12 7:45 ` [PATCH v4 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Naoya Horiguchi
2015-08-12 7:45 ` Naoya Horiguchi
2015-08-12 20:30 ` David Rientjes
2015-08-12 20:30 ` David Rientjes
2015-08-13 0:45 ` Naoya Horiguchi
2015-08-13 0:45 ` Naoya Horiguchi
2015-08-13 21:14 ` Jörn Engel
2015-08-13 21:14 ` Jörn Engel
2015-08-13 21:13 ` Jörn Engel
2015-08-13 21:13 ` Jörn Engel
2015-08-17 21:28 ` David Rientjes
2015-08-17 21:28 ` David Rientjes
2015-08-12 20:25 ` [PATCH v4 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps David Rientjes
2015-08-12 20:25 ` David Rientjes
2015-08-13 21:14 ` Jörn Engel
2015-08-13 21:14 ` Jörn Engel
2015-08-20 8:26 ` [PATCH v5 0/2] hugetlb: display per-process/per-vma usage Naoya Horiguchi
2015-08-20 8:26 ` Naoya Horiguchi
2015-08-20 8:26 ` [PATCH v5 1/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/smaps Naoya Horiguchi
2015-08-20 8:26 ` Naoya Horiguchi
2015-08-20 10:49 ` Michal Hocko
2015-08-20 10:49 ` Michal Hocko
2015-08-20 23:20 ` Naoya Horiguchi
2015-08-20 23:20 ` Naoya Horiguchi
2015-08-21 6:33 ` Michal Hocko
2015-08-21 6:33 ` Michal Hocko
2015-09-07 1:29 ` Pádraig Brady
2015-09-07 1:29 ` Pádraig Brady
2015-09-07 2:23 ` Naoya Horiguchi
2015-09-07 2:23 ` Naoya Horiguchi
2015-09-07 6:46 ` Naoya Horiguchi
2015-09-07 6:46 ` Naoya Horiguchi
2015-09-07 9:52 ` Pádraig Brady
2015-09-07 9:52 ` Pádraig Brady
2015-09-07 10:52 ` Pádraig Brady
2015-09-07 10:52 ` Pádraig Brady
2015-09-17 9:39 ` Naoya Horiguchi
2015-09-17 9:39 ` Naoya Horiguchi
2015-09-09 15:12 ` Vlastimil Babka [this message]
2015-09-09 15:12 ` Vlastimil Babka
2015-09-09 22:14 ` David Rientjes
2015-09-09 22:14 ` David Rientjes
2015-08-20 8:26 ` [PATCH v5 2/2] mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status Naoya Horiguchi
2015-08-20 8:26 ` Naoya Horiguchi
2015-08-20 11:00 ` Michal Hocko
2015-08-20 11:00 ` Michal Hocko
2015-08-20 19:49 ` David Rientjes
2015-08-20 19:49 ` David Rientjes
2015-08-21 6:32 ` Michal Hocko
2015-08-21 6:32 ` Michal Hocko
2015-08-21 16:38 ` Jörn Engel
2015-08-21 16:38 ` Jörn Engel
2015-08-20 23:34 ` Naoya Horiguchi
2015-08-20 23:34 ` Naoya Horiguchi
2015-08-21 6:53 ` Michal Hocko
2015-08-21 6:53 ` Michal Hocko
2015-08-21 16:30 ` Jörn Engel
2015-08-21 16:30 ` Jörn Engel
2015-08-24 8:51 ` Michal Hocko
2015-08-24 8:51 ` Michal Hocko
2015-08-25 23:23 ` David Rientjes
2015-08-25 23:23 ` David Rientjes
2015-08-26 6:38 ` Michal Hocko
2015-08-26 6:38 ` Michal Hocko
2015-08-26 22:02 ` David Rientjes
2015-08-26 22:02 ` David Rientjes
2015-08-27 6:48 ` Michal Hocko
2015-08-27 6:48 ` Michal Hocko
2015-08-27 17:23 ` Jörn Engel
2015-08-27 17:23 ` Jörn Engel
2015-08-27 20:44 ` David Rientjes
2015-08-27 20:44 ` David Rientjes
2015-08-31 9:12 ` Michal Hocko
2015-08-31 9:12 ` Michal Hocko
2015-09-16 0:21 ` [PATCH v1] mm: migrate: hugetlb: putback destination hugepage to active list Naoya Horiguchi
2015-09-16 0:21 ` Naoya Horiguchi
2015-09-16 2:53 ` Naoya Horiguchi
2015-09-16 2:53 ` Naoya Horiguchi
2015-08-10 0:47 ` [PATCH v3 2/3] mm: hugetlb: add VmHugetlbRSS: field in /proc/pid/status Naoya Horiguchi
2015-08-10 0:47 ` Naoya Horiguchi
2015-08-10 1:16 ` Naoya Horiguchi
2015-08-10 1:16 ` Naoya Horiguchi
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=55F04C48.7070105@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=joern@purestorage.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=nao.horiguchi@gmail.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.