Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp395581imu; Mon, 5 Nov 2018 02:42:29 -0800 (PST) X-Google-Smtp-Source: AJdET5caUC1+LM8vYPV02i4EzB4mT8IkDVHza+bYiurONcHH6vK3of85Ev1PdgYqA5OMFk0DgXHA X-Received: by 2002:a17:902:a717:: with SMTP id w23-v6mr21438008plq.24.1541414549550; Mon, 05 Nov 2018 02:42:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541414549; cv=none; d=google.com; s=arc-20160816; b=s5H0JG/qaKHgWSIzcsoyaCsJ94dT+ixNhGVZkUqLzmrEG3nqN7NJJIzBabS78KFbc7 8Pc4GEMQD/wOGMXePmKWx0XzpWOEErTY1Imd66+1T0Xqw5dGnfmtKhcKP6sN4K7lPZHP Ij69dW2/yhukuP0KRMsEvC620jBWpzpAcdqDKDEVY9fQAkIsnwRstLPO3VUMWhIp817D zxMtgNZV48QQFVrlo7z4eOThB5zKC1of/LDeV5Dbw/QT/i1XbCTIb0zeYU/YK2m+i1CF Urc0DDVxDpjhOSMOsUmQdTVpHxdBAjnOpQZAY8y0x0jXyi6w+WFfv44mm5yRho1UmfGh TNog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=tx7ZbCTDn8sAtBMb8QyEvNdMnvgCXvsH37ZBsGQbkFY=; b=s0o8eJItRNef8CGLfhGKr1IpyjBFZhjuaogqtwq8NOlfUpw+mY7GVmwAT1c155N6Fk 0FJDIVwYX03liXHzBxmlbgoFfuwCV32kIJrZvXf8jhN+g4bVCwQWuTD2m/yaKRsZmUkQ hjr4G3iBAv7hyarskS10lH9sPLLJ4PWxHBaCLCHLjb1xI2dn2oma2Hey7W09EDCthM8G G8KedblGqCkQSlt3BotC1zNUplf78ut6ej6FrAIfkPm88QbhW6JH+/mToGhQtxvOeB8C Eewonu1ISny+Ao+tsVbMVaccAxFVW/QjKeBD7ZlJZ2mjinh/LkUsN+iyPfqvnkdPd8vQ 5UyA== 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=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z67-v6si45343281pfz.5.2018.11.05.02.42.13; Mon, 05 Nov 2018 02:42:29 -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=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728789AbeKEUAt (ORCPT + 99 others); Mon, 5 Nov 2018 15:00:49 -0500 Received: from relay.sw.ru ([185.231.240.75]:46850 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726932AbeKEUAt (ORCPT ); Mon, 5 Nov 2018 15:00:49 -0500 Received: from [172.16.24.21] by relay.sw.ru with esmtp (Exim 4.90_1) (envelope-from ) id 1gJcKC-0007Kb-EN; Mon, 05 Nov 2018 13:41:40 +0300 Subject: Re: [PATCH 2/2] mm: avoid unnecessary swap_info_struct allocation To: "Huang, Ying" Cc: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, Aaron Lu References: <87sh0gbau6.fsf@yhuang-dev.intel.com> From: Vasily Averin Message-ID: <94e89c5b-a7c3-2b5f-d509-df29fb07c53c@virtuozzo.com> Date: Mon, 5 Nov 2018 13:41:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I was wrong, openVz blocks sys_swapon/swapoff syscalls inside containers. Our kernel just emulates /proc/swaps output inside containers, it is enough for 'swapon' userspace to do not fail and show required info. So I do not have any special arguments for proposed patch. On 11/5/18 8:19 AM, Vasily Averin wrote: > On 11/5/18 3:57 AM, Huang, Ying wrote: >> Vasily Averin writes: >> >>> Currently newly allocated swap_info_struct can be quickly freed. >>> This patch avoid uneccessary high-order page allocation and helps >>> to decrease the memory pressure. >> >> I think swapon/swapoff are rare operations, so it will not increase the >> memory pressure much. > > You are right, typically it should not affect usual nodes. > > It's OpenVz-specific usecase. > > OpenVz allows hosters to run hundreds of non-trusted containers per node. > Our containers have enabled "virtual swap" functionality, > and container's owners can call sys_swapon without any limits. > Containers can be restarted in any time and we would like to > decrease number of unnecessary high-order memory allocations. > >>> Signed-off-by: Vasily Averin >>> --- >>> mm/swapfile.c | 18 +++++++++++++----- >>> 1 file changed, 13 insertions(+), 5 deletions(-) >>> >>> diff --git a/mm/swapfile.c b/mm/swapfile.c >>> index 8688ae65ef58..53ec2f0cdf26 100644 >>> --- a/mm/swapfile.c >>> +++ b/mm/swapfile.c >>> @@ -2809,14 +2809,17 @@ late_initcall(max_swapfiles_check); >>> >>> static struct swap_info_struct *alloc_swap_info(void) >>> { >>> - struct swap_info_struct *p; >>> + struct swap_info_struct *p = NULL; >>> unsigned int type; >>> int i; >>> + bool force_alloc = false; >>> >>> - p = kvzalloc(sizeof(*p), GFP_KERNEL); >>> - if (!p) >>> - return ERR_PTR(-ENOMEM); >>> - >>> +retry: >>> + if (force_alloc) { >>> + p = kvzalloc(sizeof(*p), GFP_KERNEL); >>> + if (!p) >>> + return ERR_PTR(-ENOMEM); >>> + } >>> spin_lock(&swap_lock); >>> for (type = 0; type < nr_swapfiles; type++) { >>> if (!(swap_info[type]->flags & SWP_USED)) >>> @@ -2828,6 +2831,11 @@ static struct swap_info_struct *alloc_swap_info(void) >>> return ERR_PTR(-EPERM); >>> } >>> if (type >= nr_swapfiles) { >>> + if (!force_alloc) { >>> + force_alloc = true; >>> + spin_unlock(&swap_lock); >>> + goto retry; >>> + } >>> p->type = type; >>> swap_info[type] = p; >>> /* >>