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 B478AC433EF for ; Wed, 9 Mar 2022 18:01:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 481F78D0002; Wed, 9 Mar 2022 13:01:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 40BA08D0001; Wed, 9 Mar 2022 13:01:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 285C08D0002; Wed, 9 Mar 2022 13:01:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0213.hostedemail.com [216.40.44.213]) by kanga.kvack.org (Postfix) with ESMTP id 1A0978D0001 for ; Wed, 9 Mar 2022 13:01:46 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1B93F9731D for ; Wed, 9 Mar 2022 18:01:45 +0000 (UTC) X-FDA: 79225615770.22.66E656A Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf13.hostedemail.com (Postfix) with ESMTP id CBF9020056 for ; Wed, 9 Mar 2022 18:00:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646848851; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ioZlG4TTJ46/PtmS5HOswJBTZfkBKrgjXju5JFTxq0A=; b=EmMqbmYLIPBmVXcAkZdtPMApU6m7kORi7RgHFYU/ifQuTpo5x8wbYUgmHXQd09lfF2xEBw 3ZLUlNmG9vazS9QqKmwGNAWNtfqRvOOuhnKpHCt81LLBGdkyZXSsfnrWuLjODTAv7oR8t7 aUUqTCD8KknKWW35qFKDT8RHZclzByU= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-373-ReLN4eTWON-W4J5hHys-9w-1; Wed, 09 Mar 2022 13:00:49 -0500 X-MC-Unique: ReLN4eTWON-W4J5hHys-9w-1 Received: by mail-wm1-f70.google.com with SMTP id j42-20020a05600c1c2a00b00381febe402eso2913805wms.0 for ; Wed, 09 Mar 2022 10:00:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=ioZlG4TTJ46/PtmS5HOswJBTZfkBKrgjXju5JFTxq0A=; b=WClPgIPVrhw1a9ElF2ycVkk4u7HKTuTI2m9k4sXvmbbeoTFgmDiLHMj2sAtP05Xj7x WQR0SmPzXCQODb5v3e1jVWkepBwnO90HznVEIYPZgwQySSLblWoZtqDdVUNC4dUNYijf lTdLba5/UHRRwAZK3lC6djubhBQPOwtUzsiq2a3ncsfE9HBna6iiVXdkBPFP9Z2HFtn+ 8qyk+v7NF7cgj0ITOE3jrHiX4d6UAVjxda1Z6npwCza08lu/isIrY3QJSs7V5vEVP2UE PrsvEAiqFotJ0K7LKSqk6vePO88i362HDgRpZO2NTAPdTbPLiuEQ/cVSSexf8m6wvY6A OPkQ== X-Gm-Message-State: AOAM533Y/+xW0VN4uc5S8hU+rsmKkCi35P4NvlBfvl57VblCk8DX52lH 8X7r5gXWfy9L8hl55GD+bzhKT9j9we7tVsrsTEU3l6PM9aXFYgUlVONL99X7Py4/dIgYkCkteum tSeuFaOCGbQ0= X-Received: by 2002:a05:600c:2241:b0:382:9bc7:4e66 with SMTP id a1-20020a05600c224100b003829bc74e66mr439433wmm.21.1646848848581; Wed, 09 Mar 2022 10:00:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJz1vBEzmmJUDBABmo9d7yLfOhotaoWLOZ2KIAwGqRgZaOMTGz+JBTQoPp+EozsfzKUqlnWhUg== X-Received: by 2002:a05:600c:2241:b0:382:9bc7:4e66 with SMTP id a1-20020a05600c224100b003829bc74e66mr439398wmm.21.1646848848287; Wed, 09 Mar 2022 10:00:48 -0800 (PST) Received: from ?IPV6:2003:cb:c707:6300:8418:c653:d01f:3bd2? (p200300cbc70763008418c653d01f3bd2.dip0.t-ipconnect.de. [2003:cb:c707:6300:8418:c653:d01f:3bd2]) by smtp.gmail.com with ESMTPSA id v25-20020a05600c215900b0038117f41728sm5444951wml.43.2022.03.09.10.00.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Mar 2022 10:00:47 -0800 (PST) Message-ID: <32c4bd91-08cf-7318-02b7-f43452447aef@redhat.com> Date: Wed, 9 Mar 2022 19:00:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Matthew Wilcox Cc: linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , linux-mm@kvack.org, Alexander Potapenko References: <20220308141437.144919-1-david@redhat.com> <20220308141437.144919-11-david@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1 10/15] mm/page-flags: reuse PG_slab as PG_anon_exclusive for PageAnon() pages In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: CBF9020056 X-Stat-Signature: 7fhufirdsm1tc8n943opnofxb6kuobuf Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=EmMqbmYL; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf13.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-HE-Tag: 1646848852-821652 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: >> It's making the semantics of PG_slab depend on another bit in the head >> page. I agree, it's not perfect, but it's not *too* crazy. As raised in >> the cover letter, not proud of this, but I didn't really find an >> alternative for the time being. >> >>> requirement that SL[AOU]B doesn't use the bottom two bits of >> >> I think only the last bit (0x1) > > Yeah, OK, they can use three of the four possible combinations of the > bottom two bits ;-) Still, it's yet more constraints on use of struct > page, which aren't obvious (and are even upside down for the casual > observer). I don't disagree that such constraints are nasty. Having that said, I'd really like to avoid overloading PG_slab (especially, such that I don't have to mess with scripts/crash/makedumpfile). So if we can reuse MappedToDisk, that would be very nice. > >>> I have plans to get rid of PageError and PagePrivate, but those are going >>> to be too late for you. I don't think mappedtodisk has meaning for anon >>> pages, even if they're in the swapcache. It would need PG_has_hwpoisoned >> >> Are you sure it's not used if the page is in the swapcache? I have no >> detailed knowledge how file-back swap targets are handled in that >> regard. So fs experience would be highly appreciated :) > > I have two arguments here. One is based on grep: > > $ git grep mappedtodisk > fs/proc/page.c: u |= kpf_copy_bit(k, KPF_MAPPEDTODISK, PG_mappedtodisk); > include/linux/page-flags.h: PG_mappedtodisk, /* Has blocks allocated on-disk */ > include/linux/page-flags.h: PG_has_hwpoisoned = PG_mappedtodisk, > include/linux/page-flags.h:PAGEFLAG(MappedToDisk, mappedtodisk, PF_NO_TAIL) > include/trace/events/mmflags.h: {1UL << PG_mappedtodisk, "mappedtodisk" }, \ > include/trace/events/pagemap.h: (folio_test_mappedtodisk(folio) ? PAGEMAP_MAPPEDDISK : 0) | \ > mm/migrate.c: if (folio_test_mappedtodisk(folio)) > mm/migrate.c: folio_set_mappedtodisk(newfolio); > mm/truncate.c: folio_clear_mappedtodisk(folio); > tools/vm/page-types.c: [KPF_MAPPEDTODISK] = "d:mappedtodisk", > > $ git grep MappedToDisk > fs/buffer.c: SetPageMappedToDisk(page); > fs/buffer.c: if (PageMappedToDisk(page)) > fs/buffer.c: SetPageMappedToDisk(page); > fs/ext4/readpage.c: SetPageMappedToDisk(page); > fs/f2fs/data.c: SetPageMappedToDisk(page); > fs/f2fs/file.c: if (PageMappedToDisk(page)) > fs/fuse/dev.c: ClearPageMappedToDisk(newpage); > fs/mpage.c: SetPageMappedToDisk(page); > fs/nilfs2/file.c: if (PageMappedToDisk(page)) > fs/nilfs2/file.c: SetPageMappedToDisk(page); > fs/nilfs2/page.c: ClearPageMappedToDisk(page); > fs/nilfs2/page.c: SetPageMappedToDisk(dpage); > fs/nilfs2/page.c: ClearPageMappedToDisk(dpage); > fs/nilfs2/page.c: if (PageMappedToDisk(src) && !PageMappedToDisk(dst)) > fs/nilfs2/page.c: SetPageMappedToDisk(dst); > fs/nilfs2/page.c: else if (!PageMappedToDisk(src) && PageMappedToDisk(dst)) > fs/nilfs2/page.c: ClearPageMappedToDisk(dst); > fs/nilfs2/page.c: ClearPageMappedToDisk(page); > include/linux/page-flags.h:PAGEFLAG(MappedToDisk, mappedtodisk, PF_NO_TAIL) > > so you can see it's _rarely_ used, and only by specific filesystems. Right, but I spot ext4 and fs/buffer.c core functionality. That naturally makes me nervous :) > > The swap code actually bypasses the filesystem (except for network > filesystems) and submits BIOs directly (see __swap_writepage() and > swap_readpage()). There's no check for MappedToDisk, and nowhere to > set it/clear it. > > The second argument is that MappedToDisk is used for delayed allocation > on writes for filesystems. But swap is required to be allocated at > swapfile setup (so that the swap code can bypass the filesystem ...) > and so this flag is useless. I have some faint memory that there are corner cases, but maybe (hopefully) my memory is wrong. > > Of course, I may have missed something. This is complex. > Yeah, that's why I was very careful. If any FS would end up setting that flag we'd be in trouble and would have to blacklist that fs for swapping or rework it (well, if we're even able to identify such a file system). I think one sanity check I could add is making sure that PageAnonExclusive() is never set when getting a page from the swapcache in do_swap_page(). I think that would take care of the obvious bugs. -- Thanks, David / dhildenb