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 67B61C001DF for ; Wed, 16 Aug 2023 09:55:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DFFCF280003; Wed, 16 Aug 2023 05:55:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAF518D0001; Wed, 16 Aug 2023 05:55:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C770E280003; Wed, 16 Aug 2023 05:55:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id B5CD88D0001 for ; Wed, 16 Aug 2023 05:55:20 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7699F160E2B for ; Wed, 16 Aug 2023 09:55:20 +0000 (UTC) X-FDA: 81129510000.14.2822738 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 3B72F40010 for ; Wed, 16 Aug 2023 09:55:18 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eA6d5AJm; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692179718; 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=+l6CVYESkWNXZKOgwhwVdfDgv7To5sUrc78oVwNDueY=; b=JYrDWRvtTrTO3yQEhkNzbVVTz+l4vnxPqogyCZKmbup5grSZd/0Npd/ye3Cva6nxbkHvr/ KO7MmPBizfw0+Ll2vp1fsaWK/1dyqfsFW+CJ1r1IAlwS/jmgrVQ9OmyiR4v9I6f6Cvqof1 5oYfGHB+Xw2GwXPGRo+IKQLgVhbfZsg= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=eA6d5AJm; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692179718; a=rsa-sha256; cv=none; b=C6u8JbFd0aH6lR04g82wWuA7TsquOarkPJU2eMQkqGq1dsWawSzrv9FTTadAe34u090tri oPcs2ZNt0xyiE2nojU388wa1wWope6PwZ4WW8e+zh9TntzZeqjzqlFcfMJx7CCKqg14wu/ OwqOsuoTGRb9CdtfGbiqUrhcUwDC+yQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692179717; 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=+l6CVYESkWNXZKOgwhwVdfDgv7To5sUrc78oVwNDueY=; b=eA6d5AJmooGAV3OEQYJxbR3wSdwKgXpdNyPnAh0JZkLSud/xhGGVhUD2DwPZderKwh7jcS VFc6eOSdbWYrszr+iXScNm+Xo9W2v0twCjn0sr9cqTnrTN5zT6PjJ15wvbTwGaGWnAF9qq NpAhnqlUECnGpgoa+i1bT6J6l33fbV4= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-41-Nky8UBcMMf-JtLMzIvoCFA-1; Wed, 16 Aug 2023 05:55:16 -0400 X-MC-Unique: Nky8UBcMMf-JtLMzIvoCFA-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2ba7156eadfso47313431fa.0 for ; Wed, 16 Aug 2023 02:55:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692179713; x=1692784513; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+l6CVYESkWNXZKOgwhwVdfDgv7To5sUrc78oVwNDueY=; b=H5nPS+ApcMBVR8PWIZaB1G463b9/GGJ/nuTAvYExY44yzlex7/VnU072YzSC9ZkIfy EoU+zjFqcxhKgGw0pINxr58TANfJIc+f3HUyBGOqtUhJ0Z+j3sEhoaSu/iSKg9op9sf6 YThtOIRRZd/odx+Z4+g/wEZ4HUcaqMpKHIqW9IUZcTULrX+LGHORhJX94Hu9jxvvmwh7 QSDIO4CV3MUFPxJxu/S877bQqBYcEI8i2nbo99EIBWyVysbnaQUlXpDJfiOTf36tj8tx flLO20xw+1X71347UBXBCfk2RmrczGMGd8Q0RWwsSFyLOJSgTIXrRwc9RlDTOavNMWSk Ze6w== X-Gm-Message-State: AOJu0Yw0cEXHHxMaKxFc48Yy3KoEv8g18Ff5ymJrCV32Gr4SASOOLljP GYZ9B6NmfqLrRj7wOW9yRgnd5GlBb1egng4eeBa8HaUc18oe7osD7yV2jzNMeXP+pK0lDpLyXbm lZxsj0fJVMv8= X-Received: by 2002:a2e:6f16:0:b0:2b9:c676:434a with SMTP id k22-20020a2e6f16000000b002b9c676434amr1108395ljc.15.1692179713715; Wed, 16 Aug 2023 02:55:13 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGJq2vzPFGwybgPTa4U1oMr8QMSVMGXmm9UusE5Tq36K9vQoxcrWDmAYbbzDL97NzJSypd23g== X-Received: by 2002:a2e:6f16:0:b0:2b9:c676:434a with SMTP id k22-20020a2e6f16000000b002b9c676434amr1108384ljc.15.1692179713324; Wed, 16 Aug 2023 02:55:13 -0700 (PDT) Received: from ?IPV6:2003:cb:c74b:8b00:5520:fa3c:c527:592f? (p200300cbc74b8b005520fa3cc527592f.dip0.t-ipconnect.de. [2003:cb:c74b:8b00:5520:fa3c:c527:592f]) by smtp.gmail.com with ESMTPSA id l5-20020a7bc345000000b003feae747ff2sm4374556wmj.35.2023.08.16.02.55.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Aug 2023 02:55:12 -0700 (PDT) Message-ID: Date: Wed, 16 Aug 2023 11:55:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 7/9] mm: Add deferred_list page flag To: Matthew Wilcox Cc: Andrew Morton , Jens Axboe , io-uring@vger.kernel.org, linux-mm@kvack.org References: <20230815032645.1393700-1-willy@infradead.org> <20230815032645.1393700-8-willy@infradead.org> <7c1bb01d-620c-ca97-c4a2-2bb7c126c687@redhat.com> <88bdc3d2-56e4-4c09-77fe-74fb4c116893@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: 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 X-Rspam-User: X-Stat-Signature: sjbphc3h9cfx9xkz54rrd5ng4dn64ra4 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3B72F40010 X-HE-Tag: 1692179718-661282 X-HE-Meta: U2FsdGVkX1/NMmUfuMa+JMMIY9+6h7D8Ck/0+XrEWVYCa+/PKKuvwz8BxeXbk6lxw6ai8OWoVXtQBOIGXk6xAuhTqTPqsv9SlIP28xWAOsTRi54ddGcz7fdlQ3l/HVmS1jQVXUj0j85ZG3QNqDEBJQvj0/gLFcr108sZTAFPQQWid4BcuVc7582QFj774PmrK3FJ9toxIT4uATvNvHMwIkizFOuEEzo/iJuI10GEyqEHo7nbkGq6xDFp8CoaJw3xRPrymCwdc6t06glsrO/MnnZ7Lxs5AMG0HJZfY4QVnf89XdOUrbm4wedf3lw55fH890cqf0rJLCqzh4i6qBv91IE+KOG64Q042oxV48jDgK9oDtpMPcYWJSlZfsn8x2z/Zzw3gj2MM6wpCGgxU3P3+AUZybzfyXXZMJ+CIMXUuf1m6qM+9iubJPkmqs6z14UqxcviqgZPGmsCCIgS4ck3sgbkwprp7ZsFr5QbGhYxH7GcatKuy/Pc5fMfA50uye/3SVCJmgE9iKTZ0FKqMrelpZlbP1er+B5VnFnC/lTnt5pdqQsZg1InlTcB8SsR75a/Ba3yoMnHkYf1E+UfvvC4kpvVAUsT4c6s6FCZeYZ6KhZxBbU0FSZHbx7IdA6hd0z9TQ8AUHzhRUbJmx8kNEJ1GJZRtm+fLpoZNuGzc9M6bfCzxOD2F9jE2DRDZnJIwsHQibLK8QEPQ8Szcd5EMo45HZSOkftKE3AwzO7Fnha8FQIkTsVJ2ET7QdHAjhtcs1deeWfLKVG2cH7OoaKIpKO2DgP3TN4ekAcYiwtuySp8XwlcI7FJsbw+TIzgmhjjtdj86mYlrhaievIq6gBvLp1oNRHQtXp5YO2ghLW87L48AHzlnYH/JXOSKZhpPTTEEvGApYcnbfvCLYa5QC/dTe+40CV1n/XPSzaJfCRphzyiLgW0k76xWwkVj2/Chnv1hwY7A3tdXEu/5Jir4I3HB7H QaTm3CkG ajPUFQjhaP+cTTwuerTlnFbpXXbFpA4vDY48oHxUNNv62LG7RIqtoaMWO6h9nh9ay6ZiwpYIn3FNaSgEc/Y/eYyVzNzpjAfU9ZMwyFDcnv2wBZTmh37XQXKmNxVb7oES92xjeKKUInw0dXgz25+BtaOtk428zTZishB8gAk47H2vKQXurNYc5wk3whreU5IMu4ybMoFXO4ThJ3KqrmK5ZdTV8LtyTYaxUYpDF++WirsbrM6fmplr/lurNOr4UZ6H3bxREEBUXGh2nvQVYshNx1GmaD719OghYxOZMc5ruVCyBRAYhua7Zz3v81HPa+ee6I9r1AyVUsUry8tm3Ow/y5c3eEStyaUNLcSA85cEqvVQ9Y128BYQAgLy1MIhP3WcPhEq1FZplk740y3seQcZp6X14yQsv4ZfJChJMEcYq+/2Rs4I= 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 15.08.23 21:58, Matthew Wilcox wrote: > On Tue, Aug 15, 2023 at 07:27:26PM +0200, David Hildenbrand wrote: >> On 15.08.23 19:06, Matthew Wilcox wrote: >>> Theree are a lot of counters called THP and TransHuge and other variants >>> which are exposed to userspace, and the (user) assumption is that this counts >>> PMD-sized folios. If you grep around for folio_test_pmd_mappable(), >>> you'll find them. If we have folio_test_thp(), people will write: >>> >>> if (folio_test_thp(folio)) >>> __mod_lruvec_state(lruvec, NR_SHMEM_THPS, nr); >>> >>> instead of using folio_test_pmd_mappable(). >> >> So if we *really* don't want to use THP to express that we have a page, then >> let's see what these pages are: >> * can be mapped to user space >> * are transparent to most MM-related systemcalls by (un) mapping >> them in system page size (PTEs) > > * Are managed on the LRU > * Can be dirtied, written back Right, but at least hugetlb *could* be extended to do that as well (and even implement swapping). I think the biggest difference is the transparency/PTE-mapping/unmapping/ .... > >> That we can split these pages (not PTE-map, but convert from large folio to >> small folios) is one characteristic, but IMHO not the main one (and maybe >> not even required at all!). > > It's the one which distinguishes them from, say, compound pages used for > slab. Or used by device drivers. Or net pagepool, or vmalloc. There's > a lot of compound allocations out there, and the only ones which need > special treatment here are the ones which are splittable. And my point is that that is an implementation detail I'm afraid. Instead of splitting the folio into order-0 folios, you could also migrate off all data to order-0 folios and just free the large folio. Because splitting only succeeds if there are no other references on the folio, just like migration. But let's not get distracted :) > >> Maybe we can come up with a better term for "THP, but not necessarily >> PMD-sized". >> >> "Large folio" is IMHO bad. A hugetlb page is a large folio and not all large >> folios can be mapped to user space. >> >> "Transparent large folios" ? Better IMHO. > > I think this goes back to Johannes' point many months ago that we need > separate names for some things. He wants to split anon & file memory > apart (who gets to keep the name "folio" in the divorce? what do we > name the type that encompasses both folios and the other one? or do > they both get different names?) Good question. I remember discussing a type hierarchy back when you upstreamed folios. Maybe we would have "file folios" and "anon folios. > >>> Perhaps the key difference between normal compound pages and file/anon >>> compound pages is that the latter are splittable? So we can name all >>> of this: >>> >>> folio_init_splittable() >>> folio_test_splittable() >>> folio_fini_splittable() >>> >>> Maybe that's still too close to an implementation detail, but it's at >>> least talking about _a_ characteristic of the folio, even if it's not >>> the _only_ characteristic of the folio. >> >> Maybe folio_init_transparent() ... avoiding the "huge" part of it. >> >> Very open for alternatives. As expressed in other context, we really should >> figure this out soon. > > Yeah, I'm open to better naming too. At this point in the flow we're > trying to distinguish between compound pages used for slab and compound > pages used for anon/file, but that's not always going to be the case > elsewhere. Yes. Let me reply to your other mail. -- Cheers, David / dhildenb