From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45B5FC05027 for ; Wed, 8 Feb 2023 20:34:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5A1786B0074; Wed, 8 Feb 2023 15:34:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5520B6B0075; Wed, 8 Feb 2023 15:34:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41A3F6B0078; Wed, 8 Feb 2023 15:34:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 353706B0074 for ; Wed, 8 Feb 2023 15:34:19 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CF42180434 for ; Wed, 8 Feb 2023 20:34:18 +0000 (UTC) X-FDA: 80445276996.22.D8250DD Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by imf11.hostedemail.com (Postfix) with ESMTP id 0DEFF4001D for ; Wed, 8 Feb 2023 20:34:16 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=alUC6pc4; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675888457; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=x3UTKNVAFg81+ROQdV5mrZhJY+4YOTyh1X8nO1nYb4g=; b=N+80x50EwMg0TlT7LoQm4cwtdmVuXRpXQczKBBtiOGalroTzRKggLgUc66agsJ6ZUP8Bdm BAtC+bhv+qkiGvRUhR1KESh33wi7NCaEsNrfp1vgCdnx8APWVMphh0S26MLwcu/W375xwZ RBKvdK99NBWqT3J4DY31Kh+RRz3OQ/Y= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=alUC6pc4; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.42 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675888457; a=rsa-sha256; cv=none; b=3QZwjSbdLzsilx7LEfwvDzmevcSm96FKLI6nZIxuQGKmRO4l//KQwL6lbvhZqBBTDk8OnP IM3SfZkgHmwJhUXdsjNILGPBUyeTBQ/kKkiiTf1gflqYSKhB1C8nlc4ahFtODb52wy84Xf LwDjgT5gHrQ6lLLVBfS3dsF0QDD27q0= Received: by mail-ej1-f42.google.com with SMTP id jg8so387652ejc.6 for ; Wed, 08 Feb 2023 12:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=x3UTKNVAFg81+ROQdV5mrZhJY+4YOTyh1X8nO1nYb4g=; b=alUC6pc48SQEnhJO+rTZzq2elD/xe+Gw1eMwEHzIonnzHo6Kw0Gi9hkBdJ1x6RSQ5M obgdmvbS5+9Ej1+BsAbozaheeyHNm4tTsndla3yjzWDI+MOVlDi0oWHsg5HeZIyFKWtl OVBxe0IiMHydk3kuXKkDO3x0Xsp73+p1ORTwXBeuKebhfAJVAJI+/oxJqOlghbMJBpFn hJWF+E6xiDLR+kmVwwhUGihGbF8pauLkMBAN827fxh3wQfEASYbu596wHw+tPQITr7BA chVugFHdmZ41iE1kMbYafWENRBsJIVCPzdAub2gE4V/LL+OYjUsSfyGH+TTQeooJTOLx J+eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=x3UTKNVAFg81+ROQdV5mrZhJY+4YOTyh1X8nO1nYb4g=; b=CnI7YXCGJLq97CSTvQVClTD4tbEzLZ/hUfPAxdjwLC7CYPeO2rSATMoxhivgtBCZ72 ubqinacdo8KzNL96kKsCnaqzIu1TdWspNZMp4Z6D+ycVJeqo4MNZm+jSZTzodTce8gVt QytCBjZ2EP70PQKSx+hqLyYuC1BkbsoDzP7bMufmQUa4d0jBxVF0V4IkTe2GhlKcKiex 5GbMenmRhuNAUVGdGAbfTuIZu8RAUANExE02/eVkk9rgykJNwHOVoRhWMD4p2B+OkRSJ +rXAd9B+gEFCa5gXMV5dX8kll8drzOu79X/83CoUCbu8db1JRpiEvLyy0KBU7phQHB20 uxiw== X-Gm-Message-State: AO0yUKWjBhiv5BtNvr7F9uL9w04WFNvvUGLVuvOqm1g3Cr+XcjyqbH2S e3DWRWB2i2g4m3YZxlSuI86485t1ihINxoyrK5av6w== X-Google-Smtp-Source: AK7set8aN8ctARJY3EvHdGouhuwjddqw9SrrC/PuRU22EMZKiuTqRZX7+gxn8KRIqKK3msj0InP2naeZlBKd7AJTE0w= X-Received: by 2002:a17:906:37c2:b0:878:7bc7:958a with SMTP id o2-20020a17090637c200b008787bc7958amr2078814ejc.220.1675888455272; Wed, 08 Feb 2023 12:34:15 -0800 (PST) MIME-Version: 1.0 References: <20230207025259.2522793-1-mcgrof@kernel.org> <20230207025259.2522793-3-mcgrof@kernel.org> In-Reply-To: From: Yosry Ahmed Date: Wed, 8 Feb 2023 12:33:37 -0800 Message-ID: Subject: Re: [RFC 2/2] shmem: add support to ignore swap To: Matthew Wilcox Cc: Luis Chamberlain , hughd@google.com, akpm@linux-foundation.org, linux-mm@kvack.org, p.raghav@samsung.com, dave@stgolabs.net, a.manzanares@samsung.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 0DEFF4001D X-Stat-Signature: 3cj5i4zg4jmtxui5hc4wi55i6o75sfii X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675888456-938165 X-HE-Meta: U2FsdGVkX19l5OZQm+huCYv0tebcOI1czgPwgll8fjX9I1gUZiaftDA4iNKOajX2INsmKDveUWFgPwSuC8egs7//xw8079ZnrS2BEnsDT8mmH+87ktu2A8IAi34CtelQZNlorBdXYjGlkPX67NhIF955n5yOwn0S9wD6iygdWME3XRMe9j2v6VR62c5McrKYmkrlE+FaoTUtTOnUbijlkJK7wASRZT3WLLno+cmJd706PS0TQdYe7y73svSkjwPVNwWsu8Sdq6a/g85s5ADlBanOEcuzvjaA59MAJH4/vheYaxpI0eLFhDhZ1cqKOyIphJW1ZmHTwpObiSO3bBBottGJx7JX/8XptwKanE7b0DKlGVVmNj5dmdG0X02GHqk9aUHxJdOd53onScaRm+fjorVrDap2HETfm9DGsUD65VgpEx52sEnG08XQU4q3fLuu8C5fJJ95OXf1sVW0sQ9+ao+hfueQzO/fuhpykNhd2BeaCYjsLPi0A5IxPUFmvesXG3MRjEZi6weuJAV4tvCHe4V8G0TdAMc3nOp+dBKIvHxVJuIBm/0b9qx+sDJdqpokq2H/jcDjhGeXMVo/xlfHCIYcvkb5WnmHSKp82GjpUbMVP5QfwmdedbXPzK0ciktoNtL9PlH+6GAO0Tj6ogLomWH9lXVqtZk15yRaAFO4szyyFQWbtvo1qwq4WqC3y6B6jmtwaRkP8y2xDgwYBhhjSq3qiWVOIqEEs1XYyHO5NeMes0mGYiVIfnhOyzRZtO01HgB4z12HxpLvAhTHhXirU77YnjfuhVNNiVB+XA7+WfPADk1B7uXb8wGDHbQqOP2aEYtjz/Ppf1Z8MNHkjrZhJ392jJUEAxpzvpHkSBupG0AkXjjcn5PUtmdmDbj1pq1BPaBkTuedRgnJ/zchSkAXf8T2I+8qSG/m+tkc/P6+sPsIA5/O6SMcQyrUDKcAmLvL1JFouDMoFLMKizdDx2Y TOJyb36G NfhLCjfzBRP4CJhFi6yMfBH6A9s/IuUowiBdkdF54EIDQZ74t2sXP3inkls5sNTaty7cp/+Lh5zRdKHdG8AKUstGorfqcPjdUMJkKLXMWUoRfqiP7WK5UKcNry1JNgHVtvdOShCmDOuef4ovJd/OaNsW20NprQbEWpWGY3zXHtD5fHC9uTIvUqwh4WaqsV7OyMDS8cSsayi2sAV0u7PqupDuv9ZLIR+hjcn6y+p6ARGYv2Y7n3NY1xxwWJZpTpn9Idrt0gXQBvBDARmOhltgMX8f+XBsyLf0NqI5oY6pbuqbwUUY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Feb 8, 2023 at 9:45 AM Matthew Wilcox wrote: > > On Wed, Feb 08, 2023 at 08:01:01AM -0800, Luis Chamberlain wrote: > > On Tue, Feb 07, 2023 at 04:01:51AM +0000, Matthew Wilcox wrote: > > > On Mon, Feb 06, 2023 at 06:52:59PM -0800, Luis Chamberlain wrote: > > > > @@ -1334,11 +1336,15 @@ static int shmem_writepage(struct page *page, struct writeback_control *wbc) > > > > struct shmem_inode_info *info; > > > > struct address_space *mapping = folio->mapping; > > > > struct inode *inode = mapping->host; > > > > + struct shmem_sb_info *sbinfo = SHMEM_SB(inode->i_sb); > > > > swp_entry_t swap; > > > > pgoff_t index; > > > > > > > > BUG_ON(!folio_test_locked(folio)); > > > > > > > > + if (wbc->for_reclaim && unlikely(sbinfo->noswap)) > > > > + return AOP_WRITEPAGE_ACTIVATE; > > > > > > Not sure this is the best way to handle this. We'll still incur the > > > oevrhead of tracking shmem pages on the LRU, only to fail to write them > > > out when the VM thinks we should get rid of them. We'd be better off > > > not putting them on the LRU in the first place. > > > > Ah, makes sense, so in effect then if we do that then on reclaim > > we should be able to even WARN_ON(sbinfo->noswap) assuming we did > > everthing right. > > > > Hrm, we have invalidate_mapping_pages(mapping, 0, -1) but that seems a bit > > too late how about d_mark_dontcache() on shmem_get_inode() instead? > > I was thinking that the two calls to folio_add_lru() in mm/shmem.c > should be conditional on sbinfo->noswap. > Wouldn't this cause the folio to not show up in any lru lists, even the unevictable one, which may be a strange discrepancy? Perhaps we can do something like shmem_lock(), which calls mapping_set_unevictable(), which will make folio_evictable() return true and the LRUs code will take care of the rest?