From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753489AbdDENok (ORCPT ); Wed, 5 Apr 2017 09:44:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:38927 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752304AbdDENnw (ORCPT ); Wed, 5 Apr 2017 09:43:52 -0400 Subject: Re: [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure To: Dave Hansen , John Hubbard , "Huang, Ying" References: <20170320084732.3375-1-ying.huang@intel.com> <8737e3z992.fsf@yhuang-dev.intel.com> <87poh7xoms.fsf@yhuang-dev.intel.com> <2d55e06d-a0b6-771a-bba0-f9517d422789@nvidia.com> <87d1d7uoti.fsf@yhuang-dev.intel.com> <624b8e59-34e5-3538-0a93-d33d9e4ac555@nvidia.com> Cc: David Rientjes , Andrew Morton , Andi Kleen , Shaohua Li , Rik van Riel , Tim Chen , Michal Hocko , Mel Gorman , Aaron Lu , Gerald Schaefer , "Kirill A. Shutemov" , Hugh Dickins , Ingo Molnar , Vegard Nossum , linux-mm@kvack.org, linux-kernel@vger.kernel.org From: Vlastimil Babka Message-ID: Date: Wed, 5 Apr 2017 15:43:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: email@kvack.org > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f198.google.com (mail-wr0-f198.google.com [209.85.128.198]) by kanga.kvack.org (Postfix) with ESMTP id 9C6B86B039F for ; Wed, 5 Apr 2017 09:43:52 -0400 (EDT) Received: by mail-wr0-f198.google.com with SMTP id i18so1750210wrb.21 for ; Wed, 05 Apr 2017 06:43:52 -0700 (PDT) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id m3si29247139wrb.16.2017.04.05.06.43.50 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 05 Apr 2017 06:43:51 -0700 (PDT) Subject: Re: [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure References: <20170320084732.3375-1-ying.huang@intel.com> <8737e3z992.fsf@yhuang-dev.intel.com> <87poh7xoms.fsf@yhuang-dev.intel.com> <2d55e06d-a0b6-771a-bba0-f9517d422789@nvidia.com> <87d1d7uoti.fsf@yhuang-dev.intel.com> <624b8e59-34e5-3538-0a93-d33d9e4ac555@nvidia.com> From: Vlastimil Babka Message-ID: Date: Wed, 5 Apr 2017 15:43:49 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dave Hansen , John Hubbard , "Huang, Ying" Cc: David Rientjes , Andrew Morton , Andi Kleen , Shaohua Li , Rik van Riel , Tim Chen , Michal Hocko , Mel Gorman , Aaron Lu , Gerald Schaefer , "Kirill A. Shutemov" , Hugh Dickins , Ingo Molnar , Vegard Nossum , linux-mm@kvack.org, linux-kernel@vger.kernel.org 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: email@kvack.org > -- 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: email@kvack.org