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 6201DC4332F for ; Tue, 22 Nov 2022 14:08:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9DAE8E0002; Tue, 22 Nov 2022 09:08:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4DB46B0073; Tue, 22 Nov 2022 09:08:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D15948E0002; Tue, 22 Nov 2022 09:08:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id C53696B0071 for ; Tue, 22 Nov 2022 09:08:01 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 86C3F140C09 for ; Tue, 22 Nov 2022 14:08:01 +0000 (UTC) X-FDA: 80161257162.16.A6E7CE4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 99F46A0016 for ; Tue, 22 Nov 2022 14:08:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669126076; 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; bh=FvVCizhQDi+bLw8dsWFdCya/UrchTBQhvpQ3ysZKtzw=; b=VRD83q4t0VCkcT3Ol44u7GT9OcJuMWR+BYrep5PbPidVA7BmCj6El7Au8rGH8437XiYivB Hpe1uaJTb28I5pSpf4xHe2LaZjAaT0TC2cGIgIm4hihAcLWkk/RMwJ5nssruFXtFDTlDHO a09qcJ7A6V7m5guSJPJ1SWVryL/3Z4Q= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-499-F33iGtHBP7-qyCDSgkNzwA-1; Tue, 22 Nov 2022 09:05:50 -0500 X-MC-Unique: F33iGtHBP7-qyCDSgkNzwA-1 Received: by mail-wr1-f69.google.com with SMTP id g14-20020adfa48e000000b00241bfca9693so3299249wrb.8 for ; Tue, 22 Nov 2022 06:05:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:subject:cc:to:organization:from :content-language:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FvVCizhQDi+bLw8dsWFdCya/UrchTBQhvpQ3ysZKtzw=; b=xCJH6CSoRHMuFa5SIcWGrXm6eccnAG0sZUFFT3+66cLTowlhSkVKrwr3VqoZIt91ck 4vgqPpShIrH92R5KgXsk4xhEu0meoFiplNN9h8vXVeARcUU9vsoDeqCJNYuHSfE1pPLQ BTur46cwfdWDWCkXqReCzQQU4fM12qDB3yrB5IUU10HdjjjxMwkwcfD1PGGorDv3IwQL oJdWvVIvkdJ3Rli6bgkhkLFS6vNEP70R5xoHlH3y52fGNVAwm99da5+7S9aIsR05deY4 csG+M7xOu14+jXoY4PYhpLChgB5HhvLhgFs+sWSRQaK01jV1QCDhj8z0DxXiIgod9zbO X5BQ== X-Gm-Message-State: ANoB5pn0LM8bo6OIC/9ohw1FAyxuhyBIKpCcFZhjKBN3hNepFUiicBLf AxXaZv0Q03eXaBfp7G//qZSzwA7pgImL4d3/cGZvWpOYD6ScYEbV9jwfgWcYCYjL1GfRJKPYh3P 1I6YVTQspUXU= X-Received: by 2002:adf:dd4c:0:b0:241:c075:30db with SMTP id u12-20020adfdd4c000000b00241c07530dbmr4647762wrm.159.1669125925543; Tue, 22 Nov 2022 06:05:25 -0800 (PST) X-Google-Smtp-Source: AA0mqf45BP0u5dlXTS9tBk7TfX4ga1EDACnSRGuH6hbUsR+feboSnLGrcScpNUORrYu9ggowIDYU6A== X-Received: by 2002:adf:dd4c:0:b0:241:c075:30db with SMTP id u12-20020adfdd4c000000b00241c07530dbmr4647734wrm.159.1669125925190; Tue, 22 Nov 2022 06:05:25 -0800 (PST) Received: from ?IPV6:2003:cb:c706:c300:b066:75e3:f1d2:b69b? (p200300cbc706c300b06675e3f1d2b69b.dip0.t-ipconnect.de. [2003:cb:c706:c300:b066:75e3:f1d2:b69b]) by smtp.gmail.com with ESMTPSA id b3-20020a5d4d83000000b00236576c8eddsm14081329wru.12.2022.11.22.06.05.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 06:05:24 -0800 (PST) Message-ID: Date: Tue, 22 Nov 2022 15:05:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 From: David Hildenbrand Organization: Red Hat To: "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" Cc: "akpm@linux-foundation.org" Subject: 32bit architectures and __HAVE_ARCH_PTE_SWP_EXCLUSIVE X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669126081; a=rsa-sha256; cv=none; b=Ly74pyZRW18Hk71rMyadyGMUnVdR6640RYPPkC6k3e8U/gRO684aIw3JGZUxyithqkqVxF m+iMjwScF3OGfRemxcOC0Y7SyvZX7dWBcBAUlnuMRaVCrbJZ/duGv0zv3uYbEq0t04RPET XVKD5h00FFy51LzszfPWnnFWkqvP52M= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VRD83q4t; spf=pass (imf25.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669126081; 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:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=FvVCizhQDi+bLw8dsWFdCya/UrchTBQhvpQ3ysZKtzw=; b=B0EnfqCbwlYmeJUGqwAwPqM3tF1AQvGGwszrTnM5q310G/X2K/GCop9lsMGQY7tEZipQGM nmdmBtHlPBjpi58cOtoLHHX6sJRS2rrRUQCJmmx1RYrPhM0IzTKV9A5c1Sn1U+7A0hr4dh y37Q9mLpH1f1DoJPzT/2tQRG3uGV97c= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 99F46A0016 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=VRD83q4t; spf=pass (imf25.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Stat-Signature: hqnyjz5pukshyyr31t93xni8wyyo4h3n X-HE-Tag: 1669126080-735191 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: Hi all, Spoiler: is there a real use case for > 16 GiB of swap in a single file on 32bit architectures? I'm currently looking into implementing __HAVE_ARCH_PTE_SWP_EXCLUSIVE support for all remaining architectures. So far, I only implemented it for the most relevant enterprise architectures. With __HAVE_ARCH_PTE_SWP_EXCLUSIVE, we remember when unmapping a page and replacing the present PTE by a swap PTE for swapout whether the anonymous page that was mapped was exclusive (PageAnonExclusive(), i.e., not COW-shared). When refaulting that page, whereby we replace the swap PTE by a present PTE, we can reuse that information to map that page writable and avoid unnecessary page copies due to COW, even if there are still unexpected references on the page. While this would usually be a pure optimization, currently O_DIRECT still (wrongly) uses FOLL_GET instead of FOLL_PIN and can trigger in corner cases memory corruptions. So for that case, it is also a temporary fix until O_DIRECT properly uses FOLL_PIN. More details can be found in [1]. Ideally, I'd just implement __HAVE_ARCH_PTE_SWP_EXCLUSIVE for all architectures. However, __HAVE_ARCH_PTE_SWP_EXCLUSIVE requires an additional bit in the swap PTE. While mostly unproblematic on 64bit, for 32bit this implies that we'll have to "steal" one bit from the swap offset on most architectures, reducing the maximum swap size per file. Assuming we previously supported 32 GiB per swap file (e.g., hexagon, csky), this number would get reduced to 16 GiB. The kernel would automatically truncate the oversized swap area and the system would continue working by using less space of that swapfile, but ... well, is there a but? Usually (well, there is PAE on x86 ...), a 32bit system can address 4 GiB of memory. Maximum swap size recommendation seem to be around 2--3 times the memory size (2x without hibernation, 3x with hibernation). So it sounds like there is barely a use case for more swap space. Of course one can use multiple swap files. So, is anybody aware of excessive swap space requirements on 32bit? Note that I thought about storing the exclusive marker in the swap_map instead of in the swap PTE, but quickly decided to discard that idea because it results in significantly more complexity and the swap code is already horrible enough. [1] https://lkml.kernel.org/r/20220329164329.208407-1-david@redhat.com -- Thanks, David / dhildenb