linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Linux-MM <linux-mm@kvack.org>,
	mm-commits@vger.kernel.org
Subject: Re: [patch 01/11] mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations
Date: Tue, 14 Jan 2020 09:46:26 +0100	[thread overview]
Message-ID: <20200114084626.GC19428@dhcp22.suse.cz> (raw)
In-Reply-To: <90d8ba5d-9462-bcfa-3e93-2ca53f1010ba@suse.cz>

On Tue 14-01-20 09:05:57, Vlastimil Babka wrote:
> On 1/14/20 3:16 AM, Linus Torvalds wrote:
> > On Mon, Jan 13, 2020 at 4:29 PM Andrew Morton <akpm@linux-foundation.org> wrote:
> >>
> >> From: Vlastimil Babka <vbabka@suse.cz>
> >> Subject: mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations
> > 
> > I absolutely _detest_ how we've had this pattern of trying to change
> > the THP logic in a late -rc game.
> > 
> > Considering how unsuccessful some of the earlier attempts have been,
> > late -rc kernels really are *not* the time to make changes like this.
> 
> Agreed, myself would have been much more comfortable in rc1.

Yeah I do agree. The patch is a result of a regression I have reported
back in early October (http://lkml.kernel.org/r/20191001083743.GC15624@dhcp22.suse.cz).
The workload is quite trivial albeit artificial which doesn't make it
super urgent. Still something to have addressed though.  It has been
mostly ignored for quite some time until Vlastimil came with the patch
which improved the situation while not causing any other obvious problems
(http://lkml.kernel.org/r/20191029151549.GO31513@dhcp22.suse.cz).
It has been sitting in the mmotm tree since Oct 29 and in linux-next
around a similar time without any reports. 5.5-rc1 (Dec 8) would have
been a good time to target but I understand that a more time in
linux-next wouldn't hurt and targeting 5.6-rc1 should be sufficient.

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2020-01-14  8:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-14  0:28 incoming Andrew Morton
2020-01-14  0:29 ` [patch 01/11] mm, thp: tweak reclaim/compaction effort of local-only and all-node allocations Andrew Morton
2020-01-14  2:16   ` Linus Torvalds
2020-01-14  8:05     ` Vlastimil Babka
2020-01-14  8:46       ` Michal Hocko [this message]
2020-01-14  0:29 ` [patch 02/11] mm/memory_hotplug: don't free usage map when removing a re-added early section Andrew Morton
2020-01-14  0:29 ` [patch 03/11] mm/huge_memory.c: thp: fix conflict of above-47bit hint address and PMD alignment Andrew Morton
2020-01-14  0:29 ` [patch 04/11] mm/shmem.c: thp, shmem: " Andrew Morton
2020-01-14  0:29 ` [patch 05/11] mm: memcg/slab: fix percpu slab vmstats flushing Andrew Morton
2020-01-14  0:29 ` [patch 06/11] mm, debug_pagealloc: don't rely on static keys too early Andrew Morton
2020-01-14  0:29 ` [patch 07/11] mm/page-writeback.c: avoid potential division by zero in wb_min_max_ratio() Andrew Morton
2020-01-14  0:29 ` [patch 08/11] mm/page-writeback.c: use div64_ul() for u64-by-unsigned-long divide Andrew Morton
2020-01-14  0:29 ` [patch 09/11] mm/page-writeback.c: improve arithmetic divisions Andrew Morton
2020-01-14  0:29 ` [patch 10/11] mm: memcg/slab: call flush_memcg_workqueue() only if memcg workqueue is valid Andrew Morton
2020-01-14  0:29 ` [patch 11/11] mm: khugepaged: add trace status description for SCAN_PAGE_HAS_PRIVATE Andrew Morton

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=20200114084626.GC19428@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=kirill@shutemov.name \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mm-commits@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).