From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE
Date: Thu, 1 Jun 2017 14:00:48 +0300 [thread overview]
Message-ID: <20170601110048.GE30495@rapoport-lnx> (raw)
In-Reply-To: <20170531082414.GB27783@dhcp22.suse.cz>
On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote:
> On Wed 31-05-17 08:30:08, Vlastimil Babka wrote:
> > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote:
> > >
> > > I'm not sure if it should be considered a bug, the prctl is intended
> > > to use normally by wrappers so it looks optimal as implemented this
> > > way: affecting future vmas only, which will all be created after
> > > execve executed by the wrapper.
> > >
> > > What's the point of messing with the prctl so it mangles over the
> > > wrapper process own vmas before exec? Messing with those vmas is pure
> > > wasted CPUs for the wrapper use case which is what the prctl was
> > > created for.
> > >
> > > Furthermore there would be the risk a program that uses the prctl not
> > > as a wrapper and then calls the prctl to clear VM_NOHUGEPAGE from
> > > def_flags assuming the current kABI. The program could assume those
> > > vmas that were instantiated before disabling the prctl are still with
> > > VM_NOHUGEPAGE set (they would not after the change you propose).
> > >
> > > Adding a scan of all vmas to PR_SET_THP_DISABLE to clear VM_NOHUGEPAGE
> > > on existing vmas looks more complex too and less finegrined so
> > > probably more complex for userland to manage
> >
> > I would expect the prctl wouldn't iterate all vma's, nor would it modify
> > def_flags anymore. It would just set a flag somewhere in mm struct that
> > would be considered in addition to the per-vma flags when deciding
> > whether to use THP.
>
> Exactly. Something like the below (not even compile tested).
I did a quick go with the patch, compiles just fine :)
It worked for my simple examples, the THP is enabled/disabled as expected
and the vma->vm_flags are indeed unaffected.
> > We could consider whether MADV_HUGEPAGE should be
> > able to override the prctl or not.
>
> This should be a master override to any per vma setting.
Here you've introduced a change to the current behaviour. Consider the
following sequence:
{
prctl(PR_SET_THP_DISABLE);
address = mmap(...);
madvise(address, len, MADV_HUGEPAGE);
}
Currently, for the vma that backs the address
transparent_hugepage_enabled(vma) will return true, and after your patch it
will return false.
The new behaviour may be more correct, I just wanted to bring the change to
attention.
> ---
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index a3762d49ba39..9da053ced864 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -92,6 +92,7 @@ extern bool is_vma_temporary_stack(struct vm_area_struct *vma);
> (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG) && \
> ((__vma)->vm_flags & VM_HUGEPAGE))) && \
> !((__vma)->vm_flags & VM_NOHUGEPAGE) && \
> + !test_bit(MMF_DISABLE_THP, &(__vma)->vm_mm->flags) && \
> !is_vma_temporary_stack(__vma))
> #define transparent_hugepage_use_zero_page() \
> (transparent_hugepage_flags & \
> diff --git a/include/linux/khugepaged.h b/include/linux/khugepaged.h
> index 5d9a400af509..f0d7335336cd 100644
> --- a/include/linux/khugepaged.h
> +++ b/include/linux/khugepaged.h
> @@ -48,7 +48,8 @@ static inline int khugepaged_enter(struct vm_area_struct *vma,
> if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags))
> if ((khugepaged_always() ||
> (khugepaged_req_madv() && (vm_flags & VM_HUGEPAGE))) &&
> - !(vm_flags & VM_NOHUGEPAGE))
> + !(vm_flags & VM_NOHUGEPAGE) &&
> + !test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> if (__khugepaged_enter(vma->vm_mm))
> return -ENOMEM;
> return 0;
> diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
> index 69eedcef8f03..2c07b244090a 100644
> --- a/include/linux/sched/coredump.h
> +++ b/include/linux/sched/coredump.h
> @@ -68,6 +68,7 @@ static inline int get_dumpable(struct mm_struct *mm)
> #define MMF_OOM_SKIP 21 /* mm is of no interest for the OOM killer */
> #define MMF_UNSTABLE 22 /* mm is unstable for copy_from_user */
> #define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge zero page */
> +#define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
>
> #define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK)
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 8a94b4eabcaa..e48f0636c7fd 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2266,7 +2266,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> case PR_GET_THP_DISABLE:
> if (arg2 || arg3 || arg4 || arg5)
> return -EINVAL;
> - error = !!(me->mm->def_flags & VM_NOHUGEPAGE);
> + error = !!test_bit(MMF_DISABLE_THP, &me->mm->flags);
> break;
> case PR_SET_THP_DISABLE:
> if (arg3 || arg4 || arg5)
> @@ -2274,9 +2274,9 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> if (down_write_killable(&me->mm->mmap_sem))
> return -EINTR;
> if (arg2)
> - me->mm->def_flags |= VM_NOHUGEPAGE;
> + set_bit(MMF_DISABLE_THP, &me->mm->flags);
> else
> - me->mm->def_flags &= ~VM_NOHUGEPAGE;
> + clear_bit(MMF_DISABLE_THP, &me->mm->flags);
> up_write(&me->mm->mmap_sem);
> break;
> case PR_MPX_ENABLE_MANAGEMENT:
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index ce29e5cc7809..57e31f4752b3 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -818,7 +818,8 @@ khugepaged_alloc_page(struct page **hpage, gfp_t gfp, int node)
> static bool hugepage_vma_check(struct vm_area_struct *vma)
> {
> if ((!(vma->vm_flags & VM_HUGEPAGE) && !khugepaged_always()) ||
> - (vma->vm_flags & VM_NOHUGEPAGE))
> + (vma->vm_flags & VM_NOHUGEPAGE) ||
> + test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> return false;
> if (shmem_file(vma->vm_file)) {
> if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGE_PAGECACHE))
> diff --git a/mm/shmem.c b/mm/shmem.c
> index e67d6ba4e98e..27fe1bbf813b 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1977,10 +1977,11 @@ static int shmem_fault(struct vm_fault *vmf)
> }
>
> sgp = SGP_CACHE;
> - if (vma->vm_flags & VM_HUGEPAGE)
> - sgp = SGP_HUGE;
> - else if (vma->vm_flags & VM_NOHUGEPAGE)
> +
> + if ((vma->vm_flags & VM_NOHUGEPAGE) || test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> sgp = SGP_NOHUGE;
> + else if (vma->vm_flags & VM_HUGEPAGE)
> + sgp = SGP_HUGE;
>
> error = shmem_getpage_gfp(inode, vmf->pgoff, &vmf->page, sgp,
> gfp, vma, vmf, &ret);
> --
> Michal Hocko
> SUSE Labs
>
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@linux.vnet.ibm.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
"Kirill A. Shutemov" <kirill@shutemov.name>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Pavel Emelyanov <xemul@virtuozzo.com>,
linux-mm <linux-mm@kvack.org>,
lkml <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE
Date: Thu, 1 Jun 2017 14:00:48 +0300 [thread overview]
Message-ID: <20170601110048.GE30495@rapoport-lnx> (raw)
In-Reply-To: <20170531082414.GB27783@dhcp22.suse.cz>
On Wed, May 31, 2017 at 10:24:14AM +0200, Michal Hocko wrote:
> On Wed 31-05-17 08:30:08, Vlastimil Babka wrote:
> > On 05/30/2017 06:06 PM, Andrea Arcangeli wrote:
> > >
> > > I'm not sure if it should be considered a bug, the prctl is intended
> > > to use normally by wrappers so it looks optimal as implemented this
> > > way: affecting future vmas only, which will all be created after
> > > execve executed by the wrapper.
> > >
> > > What's the point of messing with the prctl so it mangles over the
> > > wrapper process own vmas before exec? Messing with those vmas is pure
> > > wasted CPUs for the wrapper use case which is what the prctl was
> > > created for.
> > >
> > > Furthermore there would be the risk a program that uses the prctl not
> > > as a wrapper and then calls the prctl to clear VM_NOHUGEPAGE from
> > > def_flags assuming the current kABI. The program could assume those
> > > vmas that were instantiated before disabling the prctl are still with
> > > VM_NOHUGEPAGE set (they would not after the change you propose).
> > >
> > > Adding a scan of all vmas to PR_SET_THP_DISABLE to clear VM_NOHUGEPAGE
> > > on existing vmas looks more complex too and less finegrined so
> > > probably more complex for userland to manage
> >
> > I would expect the prctl wouldn't iterate all vma's, nor would it modify
> > def_flags anymore. It would just set a flag somewhere in mm struct that
> > would be considered in addition to the per-vma flags when deciding
> > whether to use THP.
>
> Exactly. Something like the below (not even compile tested).
I did a quick go with the patch, compiles just fine :)
It worked for my simple examples, the THP is enabled/disabled as expected
and the vma->vm_flags are indeed unaffected.
> > We could consider whether MADV_HUGEPAGE should be
> > able to override the prctl or not.
>
> This should be a master override to any per vma setting.
Here you've introduced a change to the current behaviour. Consider the
following sequence:
{
prctl(PR_SET_THP_DISABLE);
address = mmap(...);
madvise(address, len, MADV_HUGEPAGE);
}
Currently, for the vma that backs the address
transparent_hugepage_enabled(vma) will return true, and after your patch it
will return false.
The new behaviour may be more correct, I just wanted to bring the change to
attention.
> ---
> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
> index a3762d49ba39..9da053ced864 100644
> --- a/include/linux/huge_mm.h
> +++ b/include/linux/huge_mm.h
> @@ -92,6 +92,7 @@ extern bool is_vma_temporary_stack(struct vm_area_struct *vma);
> (1<<TRANSPARENT_HUGEPAGE_REQ_MADV_FLAG) && \
> ((__vma)->vm_flags & VM_HUGEPAGE))) && \
> !((__vma)->vm_flags & VM_NOHUGEPAGE) && \
> + !test_bit(MMF_DISABLE_THP, &(__vma)->vm_mm->flags) && \
> !is_vma_temporary_stack(__vma))
> #define transparent_hugepage_use_zero_page() \
> (transparent_hugepage_flags & \
> diff --git a/include/linux/khugepaged.h b/include/linux/khugepaged.h
> index 5d9a400af509..f0d7335336cd 100644
> --- a/include/linux/khugepaged.h
> +++ b/include/linux/khugepaged.h
> @@ -48,7 +48,8 @@ static inline int khugepaged_enter(struct vm_area_struct *vma,
> if (!test_bit(MMF_VM_HUGEPAGE, &vma->vm_mm->flags))
> if ((khugepaged_always() ||
> (khugepaged_req_madv() && (vm_flags & VM_HUGEPAGE))) &&
> - !(vm_flags & VM_NOHUGEPAGE))
> + !(vm_flags & VM_NOHUGEPAGE) &&
> + !test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> if (__khugepaged_enter(vma->vm_mm))
> return -ENOMEM;
> return 0;
> diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
> index 69eedcef8f03..2c07b244090a 100644
> --- a/include/linux/sched/coredump.h
> +++ b/include/linux/sched/coredump.h
> @@ -68,6 +68,7 @@ static inline int get_dumpable(struct mm_struct *mm)
> #define MMF_OOM_SKIP 21 /* mm is of no interest for the OOM killer */
> #define MMF_UNSTABLE 22 /* mm is unstable for copy_from_user */
> #define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge zero page */
> +#define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
>
> #define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK)
>
> diff --git a/kernel/sys.c b/kernel/sys.c
> index 8a94b4eabcaa..e48f0636c7fd 100644
> --- a/kernel/sys.c
> +++ b/kernel/sys.c
> @@ -2266,7 +2266,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> case PR_GET_THP_DISABLE:
> if (arg2 || arg3 || arg4 || arg5)
> return -EINVAL;
> - error = !!(me->mm->def_flags & VM_NOHUGEPAGE);
> + error = !!test_bit(MMF_DISABLE_THP, &me->mm->flags);
> break;
> case PR_SET_THP_DISABLE:
> if (arg3 || arg4 || arg5)
> @@ -2274,9 +2274,9 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3,
> if (down_write_killable(&me->mm->mmap_sem))
> return -EINTR;
> if (arg2)
> - me->mm->def_flags |= VM_NOHUGEPAGE;
> + set_bit(MMF_DISABLE_THP, &me->mm->flags);
> else
> - me->mm->def_flags &= ~VM_NOHUGEPAGE;
> + clear_bit(MMF_DISABLE_THP, &me->mm->flags);
> up_write(&me->mm->mmap_sem);
> break;
> case PR_MPX_ENABLE_MANAGEMENT:
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index ce29e5cc7809..57e31f4752b3 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -818,7 +818,8 @@ khugepaged_alloc_page(struct page **hpage, gfp_t gfp, int node)
> static bool hugepage_vma_check(struct vm_area_struct *vma)
> {
> if ((!(vma->vm_flags & VM_HUGEPAGE) && !khugepaged_always()) ||
> - (vma->vm_flags & VM_NOHUGEPAGE))
> + (vma->vm_flags & VM_NOHUGEPAGE) ||
> + test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> return false;
> if (shmem_file(vma->vm_file)) {
> if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGE_PAGECACHE))
> diff --git a/mm/shmem.c b/mm/shmem.c
> index e67d6ba4e98e..27fe1bbf813b 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1977,10 +1977,11 @@ static int shmem_fault(struct vm_fault *vmf)
> }
>
> sgp = SGP_CACHE;
> - if (vma->vm_flags & VM_HUGEPAGE)
> - sgp = SGP_HUGE;
> - else if (vma->vm_flags & VM_NOHUGEPAGE)
> +
> + if ((vma->vm_flags & VM_NOHUGEPAGE) || test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags))
> sgp = SGP_NOHUGE;
> + else if (vma->vm_flags & VM_HUGEPAGE)
> + sgp = SGP_HUGE;
>
> error = shmem_getpage_gfp(inode, vmf->pgoff, &vmf->page, sgp,
> gfp, vma, vmf, &ret);
> --
> Michal Hocko
> SUSE Labs
>
--
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:[~2017-06-01 11:00 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-22 6:12 [PATCH] mm: introduce MADV_CLR_HUGEPAGE Mike Rapoport
2017-05-22 6:12 ` Mike Rapoport
2017-05-22 7:26 ` Anshuman Khandual
2017-05-22 7:26 ` Anshuman Khandual
2017-05-22 8:12 ` Mike Rapoport
2017-05-22 8:12 ` Mike Rapoport
2017-05-22 11:42 ` Kirill A. Shutemov
2017-05-22 11:42 ` Kirill A. Shutemov
2017-05-22 13:36 ` Mike Rapoport
2017-05-22 13:36 ` Mike Rapoport
2017-05-22 13:44 ` Kirill A. Shutemov
2017-05-22 13:44 ` Kirill A. Shutemov
2017-05-22 13:55 ` Michal Hocko
2017-05-22 13:55 ` Michal Hocko
2017-05-22 14:29 ` Mike Rapoport
2017-05-22 14:29 ` Mike Rapoport
2017-05-22 15:52 ` Vlastimil Babka
2017-05-22 15:52 ` Vlastimil Babka
2017-05-22 17:51 ` Mike Rapoport
2017-05-22 17:51 ` Mike Rapoport
2017-05-24 7:50 ` Mike Rapoport
2017-05-24 7:50 ` Mike Rapoport
2017-05-24 7:58 ` Vlastimil Babka
2017-05-24 7:58 ` Vlastimil Babka
2017-05-24 7:58 ` Vlastimil Babka
2017-05-24 10:39 ` Mike Rapoport
2017-05-24 10:39 ` Mike Rapoport
2017-05-24 11:18 ` Michal Hocko
2017-05-24 11:18 ` Michal Hocko
2017-05-24 14:25 ` Pavel Emelyanov
2017-05-24 14:25 ` Pavel Emelyanov
2017-05-24 14:27 ` Mike Rapoport
2017-05-24 14:27 ` Mike Rapoport
2017-05-24 15:22 ` Andrea Arcangeli
2017-05-24 15:22 ` Andrea Arcangeli
2017-05-30 7:44 ` Michal Hocko
2017-05-30 7:44 ` Michal Hocko
2017-05-30 7:44 ` Michal Hocko
[not found] ` <20170530074408.GA7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 10:19 ` Mike Rapoport
2017-05-30 10:19 ` Mike Rapoport
2017-05-30 10:19 ` Mike Rapoport
2017-05-30 10:39 ` Michal Hocko
2017-05-30 10:39 ` Michal Hocko
[not found] ` <20170530103930.GB7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 14:04 ` Andrea Arcangeli
2017-05-30 14:04 ` Andrea Arcangeli
2017-05-30 14:04 ` Andrea Arcangeli
2017-05-30 14:39 ` Michal Hocko
2017-05-30 14:39 ` Michal Hocko
[not found] ` <20170530143941.GK7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 14:56 ` Michal Hocko
2017-05-30 14:56 ` Michal Hocko
2017-05-30 14:56 ` Michal Hocko
[not found] ` <20170530145632.GL7969-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-30 16:06 ` Andrea Arcangeli
2017-05-30 16:06 ` Andrea Arcangeli
2017-05-30 16:06 ` Andrea Arcangeli
2017-05-31 6:30 ` Vlastimil Babka
2017-05-31 6:30 ` Vlastimil Babka
2017-05-31 8:24 ` Michal Hocko
2017-05-31 8:24 ` Michal Hocko
2017-05-31 9:27 ` Mike Rapoport
2017-05-31 9:27 ` Mike Rapoport
2017-05-31 10:24 ` Michal Hocko
2017-05-31 10:24 ` Michal Hocko
[not found] ` <20170531082414.GB27783-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-31 10:22 ` Michal Hocko
2017-05-31 10:22 ` Michal Hocko
2017-05-31 10:22 ` Michal Hocko
2017-06-01 11:00 ` Mike Rapoport [this message]
2017-06-01 11:00 ` Mike Rapoport
2017-06-01 12:27 ` Michal Hocko
2017-06-01 12:27 ` Michal Hocko
2017-05-30 15:43 ` Andrea Arcangeli
2017-05-30 15:43 ` Andrea Arcangeli
2017-05-31 12:08 ` Michal Hocko
2017-05-31 12:08 ` Michal Hocko
[not found] ` <20170531120822.GL27783-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-05-31 12:39 ` Mike Rapoprt
2017-05-31 12:39 ` Mike Rapoprt
2017-05-31 12:39 ` Mike Rapoprt
2017-05-31 14:18 ` Andrea Arcangeli
2017-05-31 14:18 ` Andrea Arcangeli
[not found] ` <20170531141809.GB302-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-05-31 14:32 ` Michal Hocko
2017-05-31 14:32 ` Michal Hocko
2017-05-31 14:32 ` Michal Hocko
2017-05-31 15:46 ` Andrea Arcangeli
2017-05-31 15:46 ` Andrea Arcangeli
2017-06-01 6:58 ` Mike Rapoport
2017-06-01 6:58 ` Mike Rapoport
2017-06-01 6:58 ` Mike Rapoport
[not found] ` <8FA5E4C2-D289-4AF5-AA09-6C199E58F9A5-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-05-31 14:19 ` Michal Hocko
2017-05-31 14:19 ` Michal Hocko
2017-05-31 14:19 ` Michal Hocko
2017-06-01 6:53 ` Mike Rapoport
2017-06-01 6:53 ` Mike Rapoport
2017-06-01 8:09 ` Michal Hocko
2017-06-01 8:09 ` Michal Hocko
[not found] ` <20170601080909.GD32677-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2017-06-01 8:35 ` Mike Rapoport
2017-06-01 8:35 ` Mike Rapoport
2017-06-01 8:35 ` Mike Rapoport
2017-06-01 13:45 ` Andrea Arcangeli
2017-06-01 13:45 ` Andrea Arcangeli
2017-06-02 9:11 ` Mike Rapoport
2017-06-02 9:11 ` Mike Rapoport
2017-05-31 9:08 ` Mike Rapoport
2017-05-31 9:08 ` Mike Rapoport
2017-05-31 9:08 ` Mike Rapoport
2017-05-31 12:05 ` Michal Hocko
2017-05-31 12:05 ` Michal Hocko
2017-05-31 12:25 ` Mike Rapoprt
2017-05-31 12:25 ` Mike Rapoprt
2017-05-24 11:31 ` Vlastimil Babka
2017-05-24 11:31 ` Vlastimil Babka
2017-05-24 14:28 ` Pavel Emelyanov
2017-05-24 14:28 ` Pavel Emelyanov
2017-05-24 14:54 ` Vlastimil Babka
2017-05-24 14:54 ` Vlastimil Babka
2017-05-24 15:13 ` Mike Rapoport
2017-05-24 15:13 ` Mike Rapoport
2017-05-22 15:33 ` kbuild test robot
2017-05-22 15:33 ` kbuild test robot
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=20170601110048.GE30495@rapoport-lnx \
--to=rppt@linux.vnet.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=vbabka@suse.cz \
--cc=xemul@virtuozzo.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.