Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp58456imu; Wed, 2 Jan 2019 14:04:10 -0800 (PST) X-Google-Smtp-Source: ALg8bN4w7BWo61pEv9DtvaALcu1c7Z1HlUZL1oqfjLuJtmnWr93aYtgXAR5tMMzg35+VyNktj7AR X-Received: by 2002:a17:902:e002:: with SMTP id ca2mr45486584plb.103.1546466650907; Wed, 02 Jan 2019 14:04:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546466650; cv=none; d=google.com; s=arc-20160816; b=LAK3NDCPwkK3hSpIFzwdsx9nRJzZPGFJRAvVqhGotcL4h2Y7cAWH8lkvsDXp7NzdwG UmoXCV2Iu9FhKXTnWl5RupCdMzbZB+vjO0JTVhlyb8DZtXYx09ZZ2Jf9BfuJhLZluys3 /HvcufsPMjt/WhlAcrUgexIoYwuLnJKQ+qzt75tussuYR+jXDxpnBfiTOagey3vdLcgB WCmcEctsUAUnS7ij7ziuyIc9SQsqxnloevlWlSHZie/UI8VI70WCNRG4rpS7InK4/nXn Ox5sv+lbDVIEbs6a/WuuIwH3bMqW2ge/LNPgxaUyw8+gxr8zAC5ut8EbTtN+QjuYANbD LmXw== 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:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature; bh=R11YRNGLg7CgD4a9KU3qTMje2Bj1pNep2Y2+/ttJnKQ=; b=xnR3cELX6hGirssYY8xoODEJGq4qzFg+qXVdil7lzs13ZmgvSb5zJRFi500HtOZy1F zyuQ338DSanoevNVc/EkGONttt8qDJAeGTXBNRZJ7Qo2cGT9KfAlcTdU4aw6AxGJM5GC qOFZZ1hCmbp/izfNRzXwQStpU1y1USZ7XkJWUCxoGfiqNTvv8yQk7UNCP3rxd6DG40i2 E7g01AmjuCr6yEJ5CdoQfHMH3I3lkRqWX1o3HVMZIFqcRY6jpdPddtZoVP74Auquc5DG lz5IAEjeUmYN31bzX/N0qBKOxGRgwMjZLtkLhDmopNjMPYFTw3phvA36QxtnQcfgVrpP 57Nw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bfOEJAnj; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j195si20036214pfd.165.2019.01.02.14.03.56; Wed, 02 Jan 2019 14:04:10 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=bfOEJAnj; 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=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727882AbfABTnV (ORCPT + 99 others); Wed, 2 Jan 2019 14:43:21 -0500 Received: from mail-pl1-f195.google.com ([209.85.214.195]:37623 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727122AbfABTnV (ORCPT ); Wed, 2 Jan 2019 14:43:21 -0500 Received: by mail-pl1-f195.google.com with SMTP id b5so14904472plr.4 for ; Wed, 02 Jan 2019 11:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=R11YRNGLg7CgD4a9KU3qTMje2Bj1pNep2Y2+/ttJnKQ=; b=bfOEJAnjnaN57sGdjQL7WTLCb47OFeG9Jx9a7m41YFvupoOw/BDT8FCtSgCQJHNKoD zrcTbdFz1BtMs2ipclejuZ5rxueDg05/fV/IZyh29nM9aRxzQaas9TxhqofVO7hOJlMX ym6tCsHNKSzn4md6EeHHz+RMawQhHjaw751q2Q81oTwlF8mCS32vaodtA7ByBw3YUl6Y xRcHoh0WtT0a35nF7I8vK6eGjnAnJlo6bNHSiOpn1jmnzL43YYgX/rP6jZwqO3/NKrd+ sZx7c+Qbx0Ns8zrG1fka+XyGxuTq9r20jHSB4uBSsjYQ9NHTdow+Ku0yrw4JZ3od8gdp 5elA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=R11YRNGLg7CgD4a9KU3qTMje2Bj1pNep2Y2+/ttJnKQ=; b=RfDL0QgLjJR2yL77yLKpBIQiagwoBsSbKdH+23Gs59cZq0Wq9M/ZdcOklZoJeX5CJa Zu6vGsq/XYIW5QQgUfhuIVTgX1GbpFq55bxETt1b1XCml5ybqd7WHa2RGxD7gr3xGKQ/ wz04KF6yx2X73LUZuQ+iUokAbktSvrC3zYNKBfhkvvqdY7y9TXYRLKEX0kMXfwoa/I8F 1AGPDh8dfhMMNtlY5ChVdNP54lHbLYfPdtjfZknt2dndFTVvuVZB+b6ASo4V4THCvcXN gH8ZvS4amktNgpGYtTFnEwY0grjhNClfEr7EkRvDPhcdiQ39+F6oCKEHVbT7VlJwVV/Z NzXA== X-Gm-Message-State: AJcUukc3i1B4ghJIOaXYTiTa9pRDMiO7yXBd6ZhIzREpEOns07bkueGW QAYe6qtdTpSHz37TUYYphSX89w== X-Received: by 2002:a17:902:9a9:: with SMTP id 38mr43746591pln.204.1546458200138; Wed, 02 Jan 2019 11:43:20 -0800 (PST) Received: from [100.112.89.103] ([104.133.8.103]) by smtp.gmail.com with ESMTPSA id w11sm64310340pgk.16.2019.01.02.11.43.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Jan 2019 11:43:18 -0800 (PST) Date: Wed, 2 Jan 2019 11:43:12 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Vineeth Pillai cc: Hugh Dickins , Matthew Wilcox , Andrew Morton , Huang Ying , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Kelley Nielsen , Rik van Riel Subject: Re: [PATCH v3 2/2] mm: rid swapoff of quadratic complexity In-Reply-To: Message-ID: References: <20181203170934.16512-1-vpillai@digitalocean.com> <20181203170934.16512-2-vpillai@digitalocean.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2 Jan 2019, Vineeth Pillai wrote: > > After reading the code again, I feel like we can make the retry logic > simpler and avoid the use of oldi. If my understanding is correct, > except for frontswap case, we reach try_to_unuse() only after we > disable the swap device. So I think, we would not be seeing any more > swap usage on the disabled swap device, after we loop through all the > process and swapin the pages on that device. In that case, we would > not need the retry logic right? Wrong. Without heavier locking that would add unwelcome overhead to common paths, we shall "always" need the retry logic. It does not come into play very often, but here are two examples of why it's needed (if I thought longer, I might find more). And in practice, yes, I sometimes saw 1 retry needed. One, the issue already discussed, of a multiply-mapped page which is swapped out, one pte swapped off, but swapped back in by concurrent fault before the last pte has been swapped off and the page finally deleted from swap cache. That swapin still references the disabled swapfile, and will need a retry to unuse (and that retry might need another). We may fix this later with an rmap walk while still holding page locked for the first pte; but even if we do, I'd still want to retain the retry logic, to avoid dependence on corner-case-free reliable rmap walks. Two, get_swap_page() allocated a swap entry for shmem file or vma just before the swapoff started, but the swapper did not reach the point of inserting that swap entry before try_to_unuse() scanned the shmem file or vma in question. > For frontswap case, the patch was missing a check for pages_to_unuse. > We would still need the retry logic, but as you mentioned, I can > easily remove the oldi logic and make it simpler. Or probably, > refactor the frontswap code out as a special case if pages_to_unuse is > still not zero after the initial loop. I don't use frontswap myself, and haven't paid any attention to the frontswap partial swapoff case (though notice now that shmem_unuse() lacks the plumbing needed for it - that needs fixing); but doubt it would be a good idea to refactor it out as a separate case. Hugh