From: Vlastimil Babka <vbabka@suse.cz> To: Dave Hansen <dave.hansen@linux.intel.com>, John Hubbard <jhubbard@nvidia.com>, "Huang, Ying" <ying.huang@intel.com> Cc: David Rientjes <rientjes@google.com>, Andrew Morton <akpm@linux-foundation.org>, Andi Kleen <ak@linux.intel.com>, Shaohua Li <shli@kernel.org>, Rik van Riel <riel@redhat.com>, Tim Chen <tim.c.chen@linux.intel.com>, Michal Hocko <mhocko@suse.com>, Mel Gorman <mgorman@techsingularity.net>, Aaron Lu <aaron.lu@intel.com>, Gerald Schaefer <gerald.schaefer@de.ibm.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>, Vegard Nossum <vegard.nossum@oracle.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure Date: Wed, 5 Apr 2017 15:43:49 +0200 [thread overview] Message-ID: <d7fd1c69-2e0e-39ec-dfd8-16269f0cb898@suse.cz> (raw) In-Reply-To: <e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com> On 03/24/2017 02:56 PM, Dave Hansen wrote: > On 03/24/2017 12:33 AM, John Hubbard wrote: >> There might be some additional information you are using to come up with >> that conclusion, that is not obvious to me. Any thoughts there? These >> calls use the same underlying page allocator (and I thought that both >> were subject to the same constraints on defragmentation, as a result of >> that). So I am not seeing any way that kmalloc could possibly be a >> less-fragmenting call than vmalloc. > > You guys are having quite a discussion over a very small point. Sorry, I know I'm too late for this discussion, just wanted to clarify a bit. > But, Ying is right. > > Let's say we have a two-page data structure. vmalloc() takes two > effectively random order-0 pages, probably from two different 2M pages > and pins them. That "kills" two 2M pages. > > kmalloc(), allocating two *contiguous* pages, is very unlikely to cross > a 2M boundary (it theoretically could). If by "theoretically" you mean we switch kmalloc() from a buddy allocator to something else, then yes. Otherwise, in the buddy allocator, it cannot cross the 2M boundary by design. > That means it will only "kill" > the possibility of a single 2M page. More 2M pages == less fragmentation. IMHO John is right that kmalloc() will reduce the number of high-order pages *in the short term*. But in the long term, vmalloc() will hurt us more due to the scattering of unmovable pages as you describe. As this is AFAIU a long-term allocation, kmalloc() should be preferred. Vlastimil > -- > 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: Dave Hansen <dave.hansen@linux.intel.com>, John Hubbard <jhubbard@nvidia.com>, "Huang, Ying" <ying.huang@intel.com> Cc: David Rientjes <rientjes@google.com>, Andrew Morton <akpm@linux-foundation.org>, Andi Kleen <ak@linux.intel.com>, Shaohua Li <shli@kernel.org>, Rik van Riel <riel@redhat.com>, Tim Chen <tim.c.chen@linux.intel.com>, Michal Hocko <mhocko@suse.com>, Mel Gorman <mgorman@techsingularity.net>, Aaron Lu <aaron.lu@intel.com>, Gerald Schaefer <gerald.schaefer@de.ibm.com>, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>, Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>, Vegard Nossum <vegard.nossum@oracle.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure Date: Wed, 5 Apr 2017 15:43:49 +0200 [thread overview] Message-ID: <d7fd1c69-2e0e-39ec-dfd8-16269f0cb898@suse.cz> (raw) In-Reply-To: <e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com> On 03/24/2017 02:56 PM, Dave Hansen wrote: > On 03/24/2017 12:33 AM, John Hubbard wrote: >> There might be some additional information you are using to come up with >> that conclusion, that is not obvious to me. Any thoughts there? These >> calls use the same underlying page allocator (and I thought that both >> were subject to the same constraints on defragmentation, as a result of >> that). So I am not seeing any way that kmalloc could possibly be a >> less-fragmenting call than vmalloc. > > You guys are having quite a discussion over a very small point. Sorry, I know I'm too late for this discussion, just wanted to clarify a bit. > But, Ying is right. > > Let's say we have a two-page data structure. vmalloc() takes two > effectively random order-0 pages, probably from two different 2M pages > and pins them. That "kills" two 2M pages. > > kmalloc(), allocating two *contiguous* pages, is very unlikely to cross > a 2M boundary (it theoretically could). If by "theoretically" you mean we switch kmalloc() from a buddy allocator to something else, then yes. Otherwise, in the buddy allocator, it cannot cross the 2M boundary by design. > That means it will only "kill" > the possibility of a single 2M page. More 2M pages == less fragmentation. IMHO John is right that kmalloc() will reduce the number of high-order pages *in the short term*. But in the long term, vmalloc() will hurt us more due to the scattering of unmovable pages as you describe. As this is AFAIU a long-term allocation, kmalloc() should be preferred. Vlastimil > -- > 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> > -- 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-04-05 13:44 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-20 8:47 [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure Huang, Ying 2017-03-20 8:47 ` Huang, Ying 2017-03-20 8:47 ` [PATCH -v2 2/2] mm, swap: Sort swap entries before free Huang, Ying 2017-03-20 8:47 ` Huang, Ying 2017-03-20 21:32 ` [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure David Rientjes 2017-03-20 21:32 ` David Rientjes 2017-03-24 2:41 ` Huang, Ying 2017-03-24 2:41 ` Huang, Ying 2017-03-24 4:27 ` John Hubbard 2017-03-24 4:27 ` John Hubbard 2017-03-24 4:52 ` Huang, Ying 2017-03-24 4:52 ` Huang, Ying 2017-03-24 6:48 ` John Hubbard 2017-03-24 6:48 ` John Hubbard 2017-03-24 7:16 ` Huang, Ying 2017-03-24 7:16 ` Huang, Ying 2017-03-24 7:33 ` John Hubbard 2017-03-24 7:33 ` John Hubbard 2017-03-24 13:56 ` Dave Hansen 2017-03-24 13:56 ` Dave Hansen 2017-03-24 16:52 ` Tim Chen 2017-03-24 16:52 ` Tim Chen 2017-03-24 18:15 ` John Hubbard 2017-03-24 18:15 ` John Hubbard 2017-03-30 16:31 ` Michal Hocko 2017-03-30 16:31 ` Michal Hocko 2017-04-01 4:47 ` Huang, Ying 2017-04-01 4:47 ` Huang, Ying 2017-04-03 8:15 ` Michal Hocko 2017-04-03 8:15 ` Michal Hocko 2017-04-05 0:49 ` Huang, Ying 2017-04-05 0:49 ` Huang, Ying 2017-04-05 13:43 ` Vlastimil Babka [this message] 2017-04-05 13:43 ` Vlastimil Babka
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=d7fd1c69-2e0e-39ec-dfd8-16269f0cb898@suse.cz \ --to=vbabka@suse.cz \ --cc=aaron.lu@intel.com \ --cc=ak@linux.intel.com \ --cc=akpm@linux-foundation.org \ --cc=dave.hansen@linux.intel.com \ --cc=gerald.schaefer@de.ibm.com \ --cc=hughd@google.com \ --cc=jhubbard@nvidia.com \ --cc=kirill.shutemov@linux.intel.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=mingo@kernel.org \ --cc=riel@redhat.com \ --cc=rientjes@google.com \ --cc=shli@kernel.org \ --cc=tim.c.chen@linux.intel.com \ --cc=vegard.nossum@oracle.com \ --cc=ying.huang@intel.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: 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.