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 474B6C02181 for ; Mon, 20 Jan 2025 12:02:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71A846B0082; Mon, 20 Jan 2025 07:02:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CAB26B0083; Mon, 20 Jan 2025 07:02:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 543E66B0085; Mon, 20 Jan 2025 07:02:35 -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 362056B0082 for ; Mon, 20 Jan 2025 07:02:35 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C16F0142B13 for ; Mon, 20 Jan 2025 12:02:34 +0000 (UTC) X-FDA: 83027693028.24.5321D6F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 2E62C10001C for ; Mon, 20 Jan 2025 12:02:32 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IhJfUFYz; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.133.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=1737374552; 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:in-reply-to:references:references:dkim-signature; bh=G+3ikOUuTQKLDnGhGljZ62C4fFiyPnmURrukyrzTzqs=; b=o00xxtXdbktUJ2HH+yoi5C5GmJMBag/bn8fJvOCbbWiVTg5reL5CLkaa142wC1UrgY5Sfv 6ame7o9ibsJwPCjlWC9+h7iUkWhxShoUKH4CxwcFGUQVNOpahSuvP3gOACd8+N1bBjaR1I oymBnosHBY8i0szhGVHpMAkUdcFQp/8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737374552; a=rsa-sha256; cv=none; b=QefoZzuDS4XMSrtrRIzlZHv49alLlSwnt9Ks9oiDX/Q2ExvekYrOBO4zCZHI9ohkPCUm/w ggXUsv3rHsEkt/Qi/2mfwP8yDHVRZsmWdRuXIa6lRNCtDfauA+OabgBIIpsq6yspGRuUdw XR8d3ofuY2BDXQLsbnsEg879G70zRa8= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IhJfUFYz; spf=pass (imf05.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737374551; 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:autocrypt:autocrypt; bh=G+3ikOUuTQKLDnGhGljZ62C4fFiyPnmURrukyrzTzqs=; b=IhJfUFYzEsaPdfxYtp/htA+3mixwkDhoIGJJM/YCesWyFMt0i4r3rYOO27lgWva0Wn7Xmu keMGwRkwPcyQ0NXrLHkIgDfb6cLcGmSauOnkPRh3H+YvqwWKPu8oNoR7deZdYhqp2MagZ7 dOC/ylRbp04X/UKw9x3weWiEop6MQ7A= 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_256_GCM_SHA384) id us-mta-686-pSdtuHhPPlSUAOKY_-MTsw-1; Mon, 20 Jan 2025 07:02:28 -0500 X-MC-Unique: pSdtuHhPPlSUAOKY_-MTsw-1 X-Mimecast-MFC-AGG-ID: pSdtuHhPPlSUAOKY_-MTsw Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-38bf5ef17a5so2596932f8f.2 for ; Mon, 20 Jan 2025 04:02:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737374547; x=1737979347; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=G+3ikOUuTQKLDnGhGljZ62C4fFiyPnmURrukyrzTzqs=; b=Q1mz/HWEsaMEDT8gxPcAJN1ujpZ+8AI0gvoS9MF2UX3Ny9r59k00QBGZmv+h42y9Xm Fq9qjh8LwLGEYWHYy6y6iylpcjafFcENqUeqITvwZRyQUFm/7ktlTFEinAVKwuY/Fa6k GBSShtNB4vbyA7lweXQYyjsxpcduSStKvlu9BrYEpwxq5k33Gcdv1feBbXYJ2p7QLUg7 j/JY4CWmEsEbV3Atz38qp6HPhjKoQlhoPpG0Fcac/f3+RmMgJ7MdZqI8Q3ywkVTEWicV 2UueCeTISHT+yAtPYw/BWgU2M9Ac9DLW9ZNwqxOHBI01yZ/EIRvnufQMM3w1nEWfODzt xHiA== X-Forwarded-Encrypted: i=1; AJvYcCVP6ssAGRpxC3ecivakAyQNT+VJSk5sa/yIHvQxLkt4PL56gSUKRg+smup9zyoUa0wNN7Cn6igghw==@kvack.org X-Gm-Message-State: AOJu0Yx9lrSKgvNd/RW0U4JU7MK26Gg8G1Q55smmnJgCwjK7VVM9a8dd n1te2mwDVUnykPnsX7YF7QwTim++zIMnW0bhu03PoHLNYqjbv7Iq/OSGGFXl+RO5Z2uexbAJZ05 0QIXZ9uglfharA5V6aSN8GV8TZo/JV13VF92V3Qfm2YFUqGFP X-Gm-Gg: ASbGnctvk/3QVNR++Lde/SC31w1c5vp/2kYSUMICUi8EFZ/weLeO+IsZ2DnnrGjHJ4T RrmtxE1xyj0vgBTSrK1cSxN/lAJ8aUICOwYoVtMecpttLfjQZIX3yEkEsEnWeBO38qv3+b2+wVp LUm4laKWWN2lP37MfFZX5qiJy8jo2cT/XWTbC8yhzb9nUS6eFxuRAz5UeBcQjRXLBsKJnIsj9Vr LskhX3M11cs4JwTEdDnV3mUWctn49jp56O6FLMdWUpzcwr7D5I9zjRyOUloIDOfYUJ6kCqCmemw BuwvyYrmMmwcpOJqgtThFIHFkZ6zX/HiEAclclV+toRmIbB/Bkk016uuEA0y7HQvP8fcM6sQrxu XLGC3afjiAkxnmein0sQOjA== X-Received: by 2002:a5d:47c2:0:b0:38a:888c:7df0 with SMTP id ffacd0b85a97d-38bf56494e9mr11786646f8f.1.1737374546938; Mon, 20 Jan 2025 04:02:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IGqLdu+Z5Ehtup/9u/RAbqEtMY+o7AVdMhpea/3zk44zhSg8ad3/ArTVFtgC+34uHYMUdr3YQ== X-Received: by 2002:a5d:47c2:0:b0:38a:888c:7df0 with SMTP id ffacd0b85a97d-38bf56494e9mr11786578f8f.1.1737374546506; Mon, 20 Jan 2025 04:02:26 -0800 (PST) Received: from ?IPV6:2003:d8:2f22:1000:d72d:fd5f:4118:c70b? (p200300d82f221000d72dfd5f4118c70b.dip0.t-ipconnect.de. [2003:d8:2f22:1000:d72d:fd5f:4118:c70b]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38bf327e327sm10005367f8f.87.2025.01.20.04.02.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Jan 2025 04:02:25 -0800 (PST) Message-ID: <5b6b2d8f-b984-41ad-8020-3550ffb81ecb@redhat.com> Date: Mon, 20 Jan 2025 13:02:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Swap Min Odrer To: Chris Li Cc: Daniel Gomez , Ryan Roberts , Barry Song , Andrew Morton , linux-mm@kvack.org, Luis Chamberlain , Pankaj Raghav , David Rientjes , Kairui Song References: <20250107094347.l37isnk3w2nmpx2i@AALNPWDAGOMEZ1.aal.scsc.local> <20250107122931.qpkn43yvs4kq3twi@AALNPWDAGOMEZ1.aal.scsc.local> <470be5fa-97d6-4045-a855-5332d3a46443@redhat.com> <20250108141406.3gen6dnlb3b4zga6@AALNPWDAGOMEZ1.aal.scsc.local> <85e2b81d-9255-4c54-b4ae-de52b2c02e7f@redhat.com> <127a4c29-e34d-401c-a642-cc73d9d1c2f6@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: B1E5oPLNARLX9_VxTZIARclR0E-Xk3Tu50vFZl8fK1Q_1737374547 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: qf5tooca9m3fg5a5enfhi64k6u1xzytn X-Rspamd-Queue-Id: 2E62C10001C X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1737374552-173367 X-HE-Meta: U2FsdGVkX1+cLs23B6XoQTxhtYSkwb8zOfK1YaNnfMclmqTmO8nnCkGMM7Apzj+Ojxg6RgNHc6J/PRsOwFzltAQF6MhP1+brd2NA9HiFvauYg6qNwCqAHraB7x4+udlRjJT2MSLDTIN2owPX+X1bJoPSivNWuLjI6HXRjOgZQSsNGwm0XXFrhBg23pR+lT78kuQWJ666YfBfRAElUBCNo3NWcADYbHGGYfbxbLuccqrSYQpN85dFHn8Icn03457pyJ0j8QR9sgYXBgDxeLwqTHacIxInTOkylA3jlksW7KfDBFMnGiyCuDOl8k9OXw7OqkB7cUcgtpAHgqMjspmXGz43n70MB6pjb3vCinJb6eaBQRiN+blA30BEMxPe9upHwodDcZ2uOPttRgvZjiSijvM0suzCegZjyppTQqs2GYMlADcmUU8PjJHv7nzFuzpSxF2KwnHIYAhthPBv/A+J5KJJctxkhbcOZ0dOJ0TnnSM6DZIyPH9QxeYy8hUkOZ6nc2CBXr6I5it/N8YKb5k82nTMRdsVJWyUSbswmMyEK4YwED2J8AQTf1WshTbU9SZd7ep6Qhm8FZDrom3Vk3zrXousRcoAPMHa+iJ6yxNxq0290WnI2mzO2KMZ1qlg+a6vWAV7WHEeOhGuhDR71R7MG0P8J4/GruyAksZj01A8mYNaT97QL9hRucFixUd+4VygkwT5cyqAwvf5gNa1qp59XjBPsahUyVYH/T3rJ4I2gx6G5ElEJEmZ2TIytdD2m58A5AFwBW4ZTOHNk+XuKBCaZNNDXpQiRgv6fpiTmWP9jsZJP22m/MtXs5wPMSh0uRJMJTYe9mkQKBmWOHqguepfSu0M9CjeZjMiKZswt/TgqN0Pm+yVtDykpiwhZnDZNwUxWG8MoAtWS8AQDvaXSGuRzAkC8wwkJHCwgPKmm9+5UM6xPYZl+am0UR0UiFEdaaiJk+ikgbTfWSUFQRVF+LY vVtQ0cRc y5N+T6tzsK0r15Xs7zCDTZoSxFN/3Ucbwv2dze1nJk1NkiSHdZQecFNFrKeYf5bkpe555vfCJ5MSezfYLNjnmpswGjjRjSutISqAMr/BGVy1LAyDRqR0JqN2Lp8rGVFLnP3i+gdlbbuSqvksx1T12A/jM7h1tGrSK+5rLYqRSm0qvqhe6aN/FTc7bkVNGSFMcbGN5OxwxX2euplFuJAM2GFglI924SeHidjbCXO9pRbIyu2MGBDUmRIyZ5fY9A5yKuP/EoUZ2xYyTSy7cU5KzepXFqB9sjxBlZTQU247mjZopVWkdcgmMapj8oxBJnd0z91pFtiLaJOAzYE+xKp4K2TofziukB6BIktW9JMQD+4N19egsd9bCJsHo4njOSi7ct+W9f8Rj5h+EAgWvwzi6e4d98eSHx+DY2MP2OSvV+mq3LUPCT2nKyaaypf+w3yHkJrScGk1trwdScBnM+9TvDSr6FcKBBnu1veysB97UqgCaDqU= 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: List-Subscribe: List-Unsubscribe: On 16.01.25 09:38, Chris Li wrote: > On Wed, Jan 8, 2025 at 1:24 PM David Hildenbrand wrote: >> >> On 08.01.25 22:19, Chris Li wrote: >>> On Wed, Jan 8, 2025 at 12:36 PM David Hildenbrand wrote: >>>> >>>>>> Maybe the swapcache could somehow abstract that? We currently have the swap >>>>>> slot allocator, that assigns slots to pages. >>>>>> >>>>>> Assuming we have a 16 KiB BS but a 4 KiB page, we might have various options >>>>>> to explore. >>>>>> >>>>>> For example, we could size swap slots 16 KiB, and assign even 4 KiB pages a >>>>>> single slot. This would waste swap space with small folios, that would go >>>>>> away with large folios. >>>>> >>>>> So batching order-0 folios in bigger slots that match the FS BS (e.g. 16 >>>>> KiB) to perform disk writes, right? >>>> >>>> Batching might be one idea, but the first idea I raised here would be >>>> that the swap slot size will match the BS (e.g., 16 KiB) and contain at >>>> most one folio. >>>> >>>> So a order-0 folio would get a single slot assigned and effectively >>>> "waste" 12 KiB of disk space. >>> >>> I prefer not to "waste" that. It will be wasted on the write >>> amplification as well. >> >> If it can be implemented fairly easily, sure! :) >> >> Looking forward to hearing about the proposal! > > Hi David, Hi! > > Sorry I have been pretty busy with other work related stuff recently. I'm in a similar situation :D > I did not have a chance to do the write up yet. > I might not be able to make the next Wednesday upstream alignment > meeting for this topic. > > Adding Kairui to the CC list, I have been collerating with him on the > swap related changes. Is this similar to https://lkml.kernel.org/r/20250116092254.204549-1-nphamcs@gmail.com ? > > I do see it is beneficial to separate out the swap cache part of the > swap entries (virtual) and block layer write locations (physical). > So the current swap allocator allocates the virtual swap entry and > still keeps the property of swap entry contiguous within a folio. The > virtual swap entry also owns the current swap count and swap cache > reclaim. Right. > > Have a lookup array to translate the virtual entry to the physical > location. The physical location also needs an allocator, but much > simpler. The physical location allocation does not participate in swap > cache reclaim, those happen in the virtual entry. Nor does it have the > swap count, only 1 bit of information used or not. The physical entry > allocation does not need to be contiguous within the folio either. Agreed. > > This redirection layer will provide the flexibility to do more. e.g. > bridge the gap between the block size between virtual entry and > physical entry. It can provide the IO batching layer to merge more > than one virtual swap entry into a larger physical writing block. > Similarly it can allow swap to write out compressed zswap/zram into > the SSD, using similar IO batching. > > The memory overhead is 4 byte per swap entry for the lookup table. > Maybe 1 bit per physical entry for that location is used or not. > > That is the key part of the idea. Okay, rings a bell, I think that was raised in some form in the past. > > There are other ideas like dynamic growing the vmalloc array pages can > be viewed as incremental local improvement, it does not change the > core data structure of swap much. Interesting, thanks! -- Cheers, David / dhildenb