stalled MM patches

stalled MM patches

[Andrew Morton]

I'm sitting on a bunch of patches of varying ages which are stuck for
various reason.  Can people please take a look some time and assist
with getting them merged, dropped or fixed?

I'll send them all out in a sec.  I have rough notes (which might be
obsolete) and additional details can be found by following the Link: in
the individual patches.

Thanks.

Subject: mm: skip HWPoisoned pages when onlining pages

  mhocko had issues with this one.

Subject: mm/mempolicy: remove redundant check in get_nodes
Subject: mm/mempolicy: fix the check of nodemask from user
Subject: mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

  Three patch series.  Stuck because vbabka wasn't happy with #3.

Subject: mm: memcontrol: eliminate raw access to stat and event counters
Subject: mm: memcontrol: implement lruvec stat functions on top of each other
Subject: mm: memcontrol: fix excessive complexity in memory.stat reporting

  Three patch series.  Stuck because #3 caused fengguang-bot to
  report "BUG: using __this_cpu_xchg() in preemptible"

Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level

  Hoping for Kirill review.  I wanted additional code comments (I
  think).  mhocko nacked it.

Subject: mm: readahead: increase maximum readahead window

  Darrick said he was going to do some testing.

Subject: fs/proc/task_mmu.c: do not show VmExe bigger than total executable virtual memory

  I had some questions, but they were responded to, whcih made my
  head spin a bit.  I guess I'll push this to Linus but would
  appreciate additional review.

Subject: mm, hugetlb: remove hugepages_treat_as_movable sysctl

  I'm holding this for additional testing.  I guess I'll merge it in
  4.16-rc1.

Subject: mm: vmscan: do not pass reclaimed slab to vmpressure

  mhocko asked for a changelog update

Subject: mm/page_owner: align with pageblock_nr pages

  mhocko sounded confused and I don't think that was resolved?

Subject: mm/vmstat.c: walk the zone in pageblock_nr_pages steps

  Joonsoo asked for a new changelog.  Various other concerns.

Subject: mm: add strictlimit knob

  This is three years old and I don't think we ever saw a convincing
  case for merging it.  Opinions>

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

Re: stalled MM patches

[Alexandru Moise]

On Thu, Nov 30, 2017 at 02:14:23PM -0800, Andrew Morton wrote:
> 
> I'm sitting on a bunch of patches of varying ages which are stuck for
> various reason.  Can people please take a look some time and assist
> with getting them merged, dropped or fixed?
> 
> I'll send them all out in a sec.  I have rough notes (which might be
> obsolete) and additional details can be found by following the Link: in
> the individual patches.
> 
> Thanks.
> 
> Subject: mm: skip HWPoisoned pages when onlining pages
> 
>   mhocko had issues with this one.
> 
> Subject: mm/mempolicy: remove redundant check in get_nodes
> Subject: mm/mempolicy: fix the check of nodemask from user
> Subject: mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
> 
>   Three patch series.  Stuck because vbabka wasn't happy with #3.
> 
> Subject: mm: memcontrol: eliminate raw access to stat and event counters
> Subject: mm: memcontrol: implement lruvec stat functions on top of each other
> Subject: mm: memcontrol: fix excessive complexity in memory.stat reporting
> 
>   Three patch series.  Stuck because #3 caused fengguang-bot to
>   report "BUG: using __this_cpu_xchg() in preemptible"
> 
> Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
> 
>   Hoping for Kirill review.  I wanted additional code comments (I
>   think).  mhocko nacked it.

TBH I'd rather give up this one if mhocko feels that there's no point to it.
Rather drop it than risk adding crap in the kernel :).

It is a bit weird though that currently we have the behavior that on some PPC platforms
you can migrate 1G hugepages but on x86_64 you cannot.

../Alex

> 
> Subject: mm: readahead: increase maximum readahead window
> 
>   Darrick said he was going to do some testing.
> 
> Subject: fs/proc/task_mmu.c: do not show VmExe bigger than total executable virtual memory
> 
>   I had some questions, but they were responded to, whcih made my
>   head spin a bit.  I guess I'll push this to Linus but would
>   appreciate additional review.
> 
> Subject: mm, hugetlb: remove hugepages_treat_as_movable sysctl
> 
>   I'm holding this for additional testing.  I guess I'll merge it in
>   4.16-rc1.
> 
> Subject: mm: vmscan: do not pass reclaimed slab to vmpressure
> 
>   mhocko asked for a changelog update
> 
> Subject: mm/page_owner: align with pageblock_nr pages
> 
>   mhocko sounded confused and I don't think that was resolved?
> 
> Subject: mm/vmstat.c: walk the zone in pageblock_nr_pages steps
> 
>   Joonsoo asked for a new changelog.  Various other concerns.
> 
> Subject: mm: add strictlimit knob
> 
>   This is three years old and I don't think we ever saw a convincing
>   case for merging it.  Opinions>

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

Re: stalled MM patches

[Michal Hocko]

On Fri 01-12-17 09:31:55, Alexandru Moise wrote:
[...]
> > Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
> > 
> >   Hoping for Kirill review.  I wanted additional code comments (I
> >   think).  mhocko nacked it.
> 
> TBH I'd rather give up this one if mhocko feels that there's no point to it.
> Rather drop it than risk adding crap in the kernel :).
> 
> It is a bit weird though that currently we have the behavior that on some PPC platforms
> you can migrate 1G hugepages but on x86_64 you cannot.

I _think_ we can apply this patch in the end. But there is more work to
be done before we can do that. PPC is probably broken in that regard as
well, we just haven't noticed before this got merged. I find the
hwpoison based reasons for merging disputable at best but this is not
serious enough to call for a revert. I am currently working on patches
to make giga pages migratable for real and then we can apply your patch
on top.

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

Re: stalled MM patches

[Kirill A. Shutemov]

On Fri, Dec 01, 2017 at 09:45:10AM +0100, Michal Hocko wrote:
> On Fri 01-12-17 09:31:55, Alexandru Moise wrote:
> [...]
> > > Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
> > > 
> > >   Hoping for Kirill review.  I wanted additional code comments (I
> > >   think).  mhocko nacked it.
> > 
> > TBH I'd rather give up this one if mhocko feels that there's no point to it.
> > Rather drop it than risk adding crap in the kernel :).
> > 
> > It is a bit weird though that currently we have the behavior that on some PPC platforms
> > you can migrate 1G hugepages but on x86_64 you cannot.
> 
> I _think_ we can apply this patch in the end. But there is more work to
> be done before we can do that. PPC is probably broken in that regard as
> well, we just haven't noticed before this got merged. I find the
> hwpoison based reasons for merging disputable at best but this is not
> serious enough to call for a revert. I am currently working on patches
> to make giga pages migratable for real and then we can apply your patch
> on top.

One way we can approach it is to make architecture code to provide
hugepage_migration_supported() with fallback to "return false;" in generic
code. It will give us more control on what can be migrated.

And we can kill CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION.

Then we can include new page sizes into migration one-by-one with proper
testing.

-- 
 Kirill A. Shutemov

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

Re: stalled MM patches

[Michal Hocko]

On Fri 01-12-17 13:11:47, Kirill A. Shutemov wrote:
> On Fri, Dec 01, 2017 at 09:45:10AM +0100, Michal Hocko wrote:
> > On Fri 01-12-17 09:31:55, Alexandru Moise wrote:
> > [...]
> > > > Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
> > > > 
> > > >   Hoping for Kirill review.  I wanted additional code comments (I
> > > >   think).  mhocko nacked it.
> > > 
> > > TBH I'd rather give up this one if mhocko feels that there's no point to it.
> > > Rather drop it than risk adding crap in the kernel :).
> > > 
> > > It is a bit weird though that currently we have the behavior that on some PPC platforms
> > > you can migrate 1G hugepages but on x86_64 you cannot.
> > 
> > I _think_ we can apply this patch in the end. But there is more work to
> > be done before we can do that. PPC is probably broken in that regard as
> > well, we just haven't noticed before this got merged. I find the
> > hwpoison based reasons for merging disputable at best but this is not
> > serious enough to call for a revert. I am currently working on patches
> > to make giga pages migratable for real and then we can apply your patch
> > on top.
> 
> One way we can approach it is to make architecture code to provide
> hugepage_migration_supported() with fallback to "return false;" in generic
> code. It will give us more control on what can be migrated.
> 
> And we can kill CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION.
> 
> Then we can include new page sizes into migration one-by-one with proper
> testing.

I do not think this is the biggest problem here. The page migration code
is basically generic for hugetlb pages. I seriously suspect anybody has
tested PGD pages migration on PPC. This is all hwpoison driven thing.

So, really, we should make giga pages migration work better first and
then play with hugepage_migration_supported. Arch specific treatment
might be needed but that is not the biggest problem we have.

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

Re: stalled MM patches

[Yisheng Xie]

Hi, Andrew

On 2017/12/1 6:14, Andrew Morton wrote:
> 
> I'm sitting on a bunch of patches of varying ages which are stuck for
> various reason.  Can people please take a look some time and assist
> with getting them merged, dropped or fixed?
> 
> I'll send them all out in a sec.  I have rough notes (which might be
> obsolete) and additional details can be found by following the Link: in
> the individual patches.
> 
> Thanks.
> 
> Subject: mm: skip HWPoisoned pages when onlining pages
> 
>   mhocko had issues with this one.
> 
> Subject: mm/mempolicy: remove redundant check in get_nodes
> Subject: mm/mempolicy: fix the check of nodemask from user
> Subject: mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
> 
>   Three patch series.  Stuck because vbabka wasn't happy with #3.
> 
I will send anther version for the patch #3.

Thanks
Yisheng Xie

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

Re: stalled MM patches

[Jan Kara]

On Thu 30-11-17 14:14:23, Andrew Morton wrote:
> Subject: mm: readahead: increase maximum readahead window
> 
>   Darrick said he was going to do some testing.

How I understood Darrick's comment was that he was surprised by XFS numbers
we measured and he'd be interested if we see them also with the latest
kernel.  Nothing against the patch as such. And I wrote him that I can
queue XFS runs on current kernel (which didn't happen - my bad). I guess
time for me to really queue a test with the latest kernel.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

Re: stalled MM patches

[Darrick J. Wong]

On Thu, Nov 30, 2017 at 02:14:23PM -0800, Andrew Morton wrote:
> 
> I'm sitting on a bunch of patches of varying ages which are stuck for
> various reason.  Can people please take a look some time and assist
> with getting them merged, dropped or fixed?
> 
> I'll send them all out in a sec.  I have rough notes (which might be
> obsolete) and additional details can be found by following the Link: in
> the individual patches.
> 
> Thanks.
> 
> Subject: mm: skip HWPoisoned pages when onlining pages
> 
>   mhocko had issues with this one.
> 
> Subject: mm/mempolicy: remove redundant check in get_nodes
> Subject: mm/mempolicy: fix the check of nodemask from user
> Subject: mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
> 
>   Three patch series.  Stuck because vbabka wasn't happy with #3.
> 
> Subject: mm: memcontrol: eliminate raw access to stat and event counters
> Subject: mm: memcontrol: implement lruvec stat functions on top of each other
> Subject: mm: memcontrol: fix excessive complexity in memory.stat reporting
> 
>   Three patch series.  Stuck because #3 caused fengguang-bot to
>   report "BUG: using __this_cpu_xchg() in preemptible"
> 
> Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
> 
>   Hoping for Kirill review.  I wanted additional code comments (I
>   think).  mhocko nacked it.
> 
> Subject: mm: readahead: increase maximum readahead window
> 
>   Darrick said he was going to do some testing.

FWIW I thought Jan said was going to do some testing on a recent kernel...

Referencing the patch itself: ext3 on 4.4 is a bit old for a 4.16 patch, yes?

--D

> 
> Subject: fs/proc/task_mmu.c: do not show VmExe bigger than total executable virtual memory
> 
>   I had some questions, but they were responded to, whcih made my
>   head spin a bit.  I guess I'll push this to Linus but would
>   appreciate additional review.
> 
> Subject: mm, hugetlb: remove hugepages_treat_as_movable sysctl
> 
>   I'm holding this for additional testing.  I guess I'll merge it in
>   4.16-rc1.
> 
> Subject: mm: vmscan: do not pass reclaimed slab to vmpressure
> 
>   mhocko asked for a changelog update
> 
> Subject: mm/page_owner: align with pageblock_nr pages
> 
>   mhocko sounded confused and I don't think that was resolved?
> 
> Subject: mm/vmstat.c: walk the zone in pageblock_nr_pages steps
> 
>   Joonsoo asked for a new changelog.  Various other concerns.
> 
> Subject: mm: add strictlimit knob
> 
>   This is three years old and I don't think we ever saw a convincing
>   case for merging it.  Opinions>

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

Re: stalled MM patches

[Jan Kara]

On Fri 01-12-17 10:30:35, Darrick J. Wong wrote:
> On Thu, Nov 30, 2017 at 02:14:23PM -0800, Andrew Morton wrote:
> > 
> > I'm sitting on a bunch of patches of varying ages which are stuck for
> > various reason.  Can people please take a look some time and assist
> > with getting them merged, dropped or fixed?
> > 
> > I'll send them all out in a sec.  I have rough notes (which might be
> > obsolete) and additional details can be found by following the Link: in
> > the individual patches.
> > 
> > Thanks.
> > 
> > Subject: mm: skip HWPoisoned pages when onlining pages
> > 
> >   mhocko had issues with this one.
> > 
> > Subject: mm/mempolicy: remove redundant check in get_nodes
> > Subject: mm/mempolicy: fix the check of nodemask from user
> > Subject: mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
> > 
> >   Three patch series.  Stuck because vbabka wasn't happy with #3.
> > 
> > Subject: mm: memcontrol: eliminate raw access to stat and event counters
> > Subject: mm: memcontrol: implement lruvec stat functions on top of each other
> > Subject: mm: memcontrol: fix excessive complexity in memory.stat reporting
> > 
> >   Three patch series.  Stuck because #3 caused fengguang-bot to
> >   report "BUG: using __this_cpu_xchg() in preemptible"
> > 
> > Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
> > 
> >   Hoping for Kirill review.  I wanted additional code comments (I
> >   think).  mhocko nacked it.
> > 
> > Subject: mm: readahead: increase maximum readahead window
> > 
> >   Darrick said he was going to do some testing.
> 
> FWIW I thought Jan said was going to do some testing on a recent kernel...

Yeah, tests are running. Will report results once I get them.

> Referencing the patch itself: ext3 on 4.4 is a bit old for a 4.16 patch, yes?

I think I already replied to this concern - this is just an unclear
statement in the changelog. ext3 == ext4 mounted with -o nodelalloc (that
happens today if you try to mount a filesystem using ext3 fstype).

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

Re: stalled MM patches

[Vinayak Menon]

On 12/1/2017 3:44 AM, Andrew Morton wrote:
> I'm sitting on a bunch of patches of varying ages which are stuck for
> various reason.  Can people please take a look some time and assist
> with getting them merged, dropped or fixed?
>
> I'll send them all out in a sec.  I have rough notes (which might be
> obsolete) and additional details can be found by following the Link: in
> the individual patches.
>
> Thanks.
>
> Subject: mm: skip HWPoisoned pages when onlining pages
>
>   mhocko had issues with this one.
>
> Subject: mm/mempolicy: remove redundant check in get_nodes
> Subject: mm/mempolicy: fix the check of nodemask from user
> Subject: mm/mempolicy: add nodes_empty check in SYSC_migrate_pages
>
>   Three patch series.  Stuck because vbabka wasn't happy with #3.
>
> Subject: mm: memcontrol: eliminate raw access to stat and event counters
> Subject: mm: memcontrol: implement lruvec stat functions on top of each other
> Subject: mm: memcontrol: fix excessive complexity in memory.stat reporting
>
>   Three patch series.  Stuck because #3 caused fengguang-bot to
>   report "BUG: using __this_cpu_xchg() in preemptible"
>
> Subject: mm/madvise: enable soft offline of HugeTLB pages at PUD level
>
>   Hoping for Kirill review.  I wanted additional code comments (I
>   think).  mhocko nacked it.
>
> Subject: mm: readahead: increase maximum readahead window
>
>   Darrick said he was going to do some testing.
>
> Subject: fs/proc/task_mmu.c: do not show VmExe bigger than total executable virtual memory
>
>   I had some questions, but they were responded to, whcih made my
>   head spin a bit.  I guess I'll push this to Linus but would
>   appreciate additional review.
>
> Subject: mm, hugetlb: remove hugepages_treat_as_movable sysctl
>
>   I'm holding this for additional testing.  I guess I'll merge it in
>   4.16-rc1.
>
> Subject: mm: vmscan: do not pass reclaimed slab to vmpressure
>
>   mhocko asked for a changelog update
>
Michal was of the opinion that we should reconsider how we calculate vmpressure rather than
making this fix. I am okay if this patch is dropped, but I feel it would be better if slab reclaimed
pages are skipped from vmpressure calculation because
1) Adding only reclaimed pages to a model which works on scanned and reclaimed seems like
a wrong thing.
2) As Minchan mentioned, the cost model is different and thus adding slab reclaimed would not
be a right thing to do.

But Michal's question was whether the model would be better if we skip slab reclaimed pages.
I am not sure about this, but at least vmpressure without slab noise gives the pressure on LRU
and we have been using this in deciding the right point to trigger lowmemorykiller kills. And we
have seen that slab noise make the vmpressure value unreliable at least for lowmemorykiller.
But I agree this is just one workload, so I don't have more points in favor of this patch.

Thanks,
Vinayak

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