Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2088901imd; Sun, 4 Nov 2018 16:57:38 -0800 (PST) X-Google-Smtp-Source: AJdET5exk21ZYKFjz4Kq5aF5ybI5SbwZKcsKKT78JsDJK3JA5nl3yrFsgTxIirwjkkVwBH1ti0q0 X-Received: by 2002:a17:902:6909:: with SMTP id j9-v6mr19484438plk.221.1541379458645; Sun, 04 Nov 2018 16:57:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541379458; cv=none; d=google.com; s=arc-20160816; b=FzT11w3SoxzUM1K31e/6ReBvkgjjNhIqjP8edJlnfqAPDa3BOKB95tIbzc6SQJTxCp 8g668bniY0PqULwpGEhYGxsO+JUll1cs33Hi09Hx7+YGoHoubXGCBF2RH7A0QZmRe1lt 1ti5L3BHmzxKIg2Q9IHEoe9PtNr+UYwOTQmv7c+1EOqGpCg8Fa7r+v/udVLjY+BRwZ45 kyPZCyUn7dS3w+kBQ/w75o7Smm/iJMSsVuK62TIbQfMaDaCP5ZUlKpe1V1IoP5N8eWF5 vtiAjcbcZTffAEUm7mEMqP9o0mGvk0QyTUlsFCtcQ6k4BIzDMyqbt3aU6B2wOZUW8h0y TbkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=fzEEKCsQ8XEQx2AYXaeiwUiVs+XK9Vc/bzhSy3rTCgs=; b=Br6UAmaqoTtQ4wkR6ixBoD8SzwEuQ3WlLCluIx/hkf4LjWttvkGc02xWMQjutDN6O8 IPFmqS4etscyvkDsvzAsBy4xkKUe6vwrk12gkR4LEMMvMI7XoD+3OYu1bP3JDPXJdhbF 6fCuZABRyf2E72b5q2DlKkNT+M3ZP1VcIjjqFCsoewQGVCHsrPpygQntStKFzxAq1l/e 0M0dvg41LBaf95X/q4m8xso9MnTmIn9Q9hL9i855c0HpZMo7G1gCbWOlPIWRZvBU869K PIlFCwyLjFw0V7M5oCn3a/CfJEmDTX1kuTjewQHI7IIVKyrC95zTLpAYSuv2FtRAKSo4 Q/BQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m6-v6si18096385pls.35.2018.11.04.16.57.23; Sun, 04 Nov 2018 16:57:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727667AbeKEKHD (ORCPT + 99 others); Mon, 5 Nov 2018 05:07:03 -0500 Received: from mga14.intel.com ([192.55.52.115]:9299 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726173AbeKEKHD (ORCPT ); Mon, 5 Nov 2018 05:07:03 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2018 16:50:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,466,1534834800"; d="scan'208";a="105239613" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.13.27]) by fmsmga001.fm.intel.com with ESMTP; 04 Nov 2018 16:50:04 -0800 From: "Huang\, Ying" To: Vasily Averin Cc: , Andrew Morton , , "Aaron Lu" Subject: Re: [PATCH 1/2] mm: use kvzalloc for swap_info_struct allocation References: <37b60523-d085-71e9-fef9-80b90bfcef18@virtuozzo.com> Date: Mon, 05 Nov 2018 08:50:04 +0800 In-Reply-To: <37b60523-d085-71e9-fef9-80b90bfcef18@virtuozzo.com> (Vasily Averin's message of "Mon, 5 Nov 2018 01:13:04 +0300") Message-ID: <87wopsbb5v.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vasily Averin writes: > commit a2468cc9bfdf ("swap: choose swap device according to numa node") > increased size of swap_info_struct up to 44 Kbytes, now it requires > 4th order page. Why swap_info_struct could be so large? Because MAX_NUMNODES could be thousands so that 'avail_lists' field could be tens KB? If so, I think it's fair to use kvzalloc(). Can you add one line comment? Because struct swap_info_struct is quite small in default configuration. Best Regards, Huang, Ying > Switch to kvzmalloc allows to avoid unexpected allocation failures. > > Signed-off-by: Vasily Averin > --- > mm/swapfile.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index 644f746e167a..8688ae65ef58 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -2813,7 +2813,7 @@ static struct swap_info_struct *alloc_swap_info(void) > unsigned int type; > int i; > > - p = kzalloc(sizeof(*p), GFP_KERNEL); > + p = kvzalloc(sizeof(*p), GFP_KERNEL); > if (!p) > return ERR_PTR(-ENOMEM); > > @@ -2824,7 +2824,7 @@ static struct swap_info_struct *alloc_swap_info(void) > } > if (type >= MAX_SWAPFILES) { > spin_unlock(&swap_lock); > - kfree(p); > + kvfree(p); > return ERR_PTR(-EPERM); > } > if (type >= nr_swapfiles) { > @@ -2838,7 +2838,7 @@ static struct swap_info_struct *alloc_swap_info(void) > smp_wmb(); > nr_swapfiles++; > } else { > - kfree(p); > + kvfree(p); > p = swap_info[type]; > /* > * Do not memset this entry: a racing procfs swap_next()