From: Michal Hocko <mhocko@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>, David Rientjes <rientjes@google.com>, Andrea Argangeli <andrea@kernel.org>, Zi Yan <zi.yan@cs.rutgers.edu>, Stefan Priebe - Profihost AG <s.priebe@profihost.ag>, "Kirill A. Shutemov" <kirill@shutemov.name>, <linux-mm@kvack.org>, LKML <linux-kernel@vger.kernel.org> Subject: [PATCH 0/2] thp nodereclaim fixes Date: Tue, 25 Sep 2018 14:03:24 +0200 [thread overview] Message-ID: <20180925120326.24392-1-mhocko@kernel.org> (raw) Hi, this has been brought up by Andrea [1] and he proposed two different fixes for the regression. I have proposed an alternative fix [2]. I have changed my mind in the end because whatever fix we end up with it should be backported to the stable trees so going with a minimalistic one is preferred so I have got back to the Andrea's second proposed solution [3] in the end. I have just reworded the changelog to reflect other bug report with the stall information. My primary concern about [3] was that the __GFP_THISNODE logic should be placed in alloc_hugepage_direct_gfpmask which I've done on top of the fix as a cleanup (patch 2) and it doesn't need to be backported to the stable tree. I am still not happy that the David's workload will regress as a result but we should really focus on the default behavior and come with a more robust solution for specialized one for those who have more restrictive NUMA preferences. I am thinking about a new numa policy that would mimic node reclaim behavior and I am willing to work on that but we really have to fix the regression first and that is the patch 1. Thoughts, alternative patches? [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com [2] http://lkml.kernel.org/r/20180830064732.GA2656@dhcp22.suse.cz [3] http://lkml.kernel.org/r/20180820032640.9896-2-aarcange@redhat.com
WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: Mel Gorman <mgorman@suse.de>, Vlastimil Babka <vbabka@suse.cz>, David Rientjes <rientjes@google.com>, Andrea Argangeli <andrea@kernel.org>, Zi Yan <zi.yan@cs.rutgers.edu>, Stefan Priebe - Profihost AG <s.priebe@profihost.ag>, "Kirill A. Shutemov" <kirill@shutemov.name>, linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org> Subject: [PATCH 0/2] thp nodereclaim fixes Date: Tue, 25 Sep 2018 14:03:24 +0200 [thread overview] Message-ID: <20180925120326.24392-1-mhocko@kernel.org> (raw) Hi, this has been brought up by Andrea [1] and he proposed two different fixes for the regression. I have proposed an alternative fix [2]. I have changed my mind in the end because whatever fix we end up with it should be backported to the stable trees so going with a minimalistic one is preferred so I have got back to the Andrea's second proposed solution [3] in the end. I have just reworded the changelog to reflect other bug report with the stall information. My primary concern about [3] was that the __GFP_THISNODE logic should be placed in alloc_hugepage_direct_gfpmask which I've done on top of the fix as a cleanup (patch 2) and it doesn't need to be backported to the stable tree. I am still not happy that the David's workload will regress as a result but we should really focus on the default behavior and come with a more robust solution for specialized one for those who have more restrictive NUMA preferences. I am thinking about a new numa policy that would mimic node reclaim behavior and I am willing to work on that but we really have to fix the regression first and that is the patch 1. Thoughts, alternative patches? [1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com [2] http://lkml.kernel.org/r/20180830064732.GA2656@dhcp22.suse.cz [3] http://lkml.kernel.org/r/20180820032640.9896-2-aarcange@redhat.com
next reply other threads:[~2018-09-25 12:03 UTC|newest] Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-25 12:03 Michal Hocko [this message] 2018-09-25 12:03 ` [PATCH 0/2] thp nodereclaim fixes Michal Hocko 2018-09-25 12:03 ` [PATCH 1/2] mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings Michal Hocko 2018-09-25 12:03 ` Michal Hocko 2018-09-25 12:20 ` Mel Gorman 2018-09-25 12:30 ` Michal Hocko 2018-10-04 20:16 ` David Rientjes 2018-10-04 21:10 ` Andrea Arcangeli 2018-10-04 23:05 ` David Rientjes 2018-10-06 3:19 ` Andrea Arcangeli 2018-10-05 7:38 ` Mel Gorman 2018-10-05 20:35 ` David Rientjes 2018-10-05 23:21 ` Andrea Arcangeli 2018-10-08 20:41 ` David Rientjes 2018-10-09 9:48 ` Mel Gorman 2018-10-09 12:27 ` Michal Hocko 2018-10-09 13:00 ` Mel Gorman 2018-10-09 14:25 ` Michal Hocko 2018-10-09 15:16 ` Mel Gorman 2018-10-09 23:03 ` Andrea Arcangeli 2018-10-10 21:19 ` David Rientjes 2018-10-15 22:30 ` David Rientjes 2018-10-15 22:44 ` Andrew Morton 2018-10-15 23:19 ` Andrea Arcangeli 2018-10-22 20:54 ` David Rientjes 2018-10-16 7:46 ` Mel Gorman 2018-10-16 22:37 ` Andrew Morton 2018-10-16 23:11 ` Andrea Arcangeli 2018-10-16 23:16 ` Andrew Morton 2018-10-17 7:08 ` Michal Hocko 2018-10-17 9:00 ` Mel Gorman 2018-10-22 21:04 ` David Rientjes 2018-10-23 1:27 ` Zi Yan 2018-10-23 1:27 ` Zi Yan 2018-10-28 21:45 ` David Rientjes 2018-10-23 7:57 ` Mel Gorman 2018-10-23 8:38 ` Mel Gorman 2018-10-15 22:57 ` Andrea Arcangeli 2018-10-22 20:45 ` David Rientjes 2018-10-09 22:17 ` David Rientjes 2018-10-09 22:51 ` Andrea Arcangeli 2018-10-10 7:54 ` Vlastimil Babka 2018-10-10 21:00 ` David Rientjes 2018-10-09 13:08 ` Vlastimil Babka 2018-10-09 22:21 ` Andrea Arcangeli 2018-10-29 5:17 ` Balbir Singh 2018-10-29 9:00 ` Michal Hocko 2018-10-29 9:42 ` Balbir Singh 2018-10-29 10:08 ` Michal Hocko 2018-10-29 10:56 ` Andrea Arcangeli 2018-09-25 12:03 ` [PATCH 2/2] mm, thp: consolidate THP gfp handling into alloc_hugepage_direct_gfpmask Michal Hocko 2018-09-25 12:03 ` Michal Hocko 2018-09-26 13:30 ` Kirill A. Shutemov 2018-09-26 14:17 ` Michal Hocko 2018-09-26 14:22 ` Michal Hocko 2018-10-19 2:11 ` Andrew Morton 2018-10-19 8:06 ` Michal Hocko 2018-10-22 13:27 ` Vlastimil Babka 2018-10-24 23:17 ` Andrew Morton 2018-10-25 4:56 ` Vlastimil Babka 2018-10-25 16:14 ` Michal Hocko 2018-10-25 16:18 ` Andrew Morton 2018-10-25 16:45 ` Michal Hocko 2018-10-22 13:15 ` Vlastimil Babka 2018-10-22 13:30 ` Michal Hocko 2018-10-22 13:35 ` Vlastimil Babka 2018-10-22 13:46 ` Michal Hocko 2018-10-22 13:53 ` Vlastimil Babka 2018-10-04 20:17 ` David Rientjes 2018-10-04 21:49 ` Zi Yan 2018-10-09 12:36 ` Michal Hocko 2018-09-26 13:08 ` linux-mm@ archive on lore.kernel.org (Was: [PATCH 0/2] thp nodereclaim fixes) Kirill A. Shutemov 2018-09-26 13:14 ` Michal Hocko 2018-09-26 22:22 ` Andrew Morton 2018-09-26 23:08 ` Mel Gorman 2018-09-27 0:47 ` Konstantin Ryabitsev 2018-09-26 15:25 ` Konstantin Ryabitsev 2018-09-27 11:30 ` Kirill A. Shutemov
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=20180925120326.24392-1-mhocko@kernel.org \ --to=mhocko@kernel.org \ --cc=akpm@linux-foundation.org \ --cc=andrea@kernel.org \ --cc=kirill@shutemov.name \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=rientjes@google.com \ --cc=s.priebe@profihost.ag \ --cc=vbabka@suse.cz \ --cc=zi.yan@cs.rutgers.edu \ /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: linkBe 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.