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 DEDFCEB64D7 for ; Sun, 18 Jun 2023 18:32:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1715F6B0071; Sun, 18 Jun 2023 14:32:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 121866B0072; Sun, 18 Jun 2023 14:32:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F04EC6B0075; Sun, 18 Jun 2023 14:32:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E0D7C6B0071 for ; Sun, 18 Jun 2023 14:32:54 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B863580304 for ; Sun, 18 Jun 2023 18:32:54 +0000 (UTC) X-FDA: 80916715068.05.16C1CA6 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf11.hostedemail.com (Postfix) with ESMTP id D84CE4001B for ; Sun, 18 Jun 2023 18:32:52 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=5J+ByrPz; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.47 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=1687113172; 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=grb4k9rcKHfeGi29uyBKq1vskbqp8uHxrZwULjij13A=; b=JtKueUb95Gqs/FzHoYgmvjz2/lz//IjffzAn0nXElhtv0MNgGWf7RPBeeEzLHQ+qwTaned QUOrwl8MdRENZm48hsnDGydHcPo2EowB1A9/2Wg5W2J79VP0OfA99R+0j5aUcTjYn3bxoP FadGW6wI0sHpLZFhHJ1jm48UlCb+Zpw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687113173; a=rsa-sha256; cv=none; b=TwZTHa4bogPW4gVWW81LC5ue+nedo921cTLF3jPGKAxG0FEl3SZ4blagd+Ph3Ll2iG3Zzn wwtEsHRlLR+FiMU4HqdcUWrWd+AXifVoS15lfEKiMWUiXTbfN+T56nXWee4Z+x/sQ8zIaL 8MsE7q9SQCifMzzw9rAPRMLdefd32kU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=5J+ByrPz; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-9887ebe16d0so93476566b.2 for ; Sun, 18 Jun 2023 11:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1687113171; x=1689705171; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=grb4k9rcKHfeGi29uyBKq1vskbqp8uHxrZwULjij13A=; b=5J+ByrPzzTeRM4palylTnHVbjrHE0spmjZPRD5L9SpVLaw8kfIRdoAGT7GF0HPE8ZH EL3j6NRD9AoMhmR6jLQGLeq1M6LmPHRG8qBJEHdbQeRAwI7lLvmfL06zMUFUncL33jhF tc5DrVR0arPD07AwL7LPRkhWoxRw3dcfKqz85Mzw3868vsi43gRSZ7obVrbiUkc66XYT +aDPfLsFNUjyKm7XTIfbHXuWphpiSzdL08Id9MWN9kImf7+DV/5SLQmls1R8iCNXgPUz YQn5/dAfD/reULvvHPQ1L0hs6CdMFVc6fKtQdFt/GYDRRmOscIBpOr1DYSfAssDUX1SF qWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687113171; x=1689705171; h=content-transfer-encoding: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=grb4k9rcKHfeGi29uyBKq1vskbqp8uHxrZwULjij13A=; b=g7YYivwECC1fyLvbtXmkw9MqQYJeQucjLsLmpt+MZvcPmfSAAxuTE0SULq7C6+QFUW c/IN5q8vo7LZQ/6n6H2v2AXM3/m/TTqEciICApAcMWdU4MdjxrLBOQtFkMhaOyF7QmyU bvu3TcstH6uDCKd70LZfmv1vPerJgeA4er6tO9u5fKjpueAX+vLhyAYwJBGOZoXhw+Ob 2vwG/+Veb942ZiiWOg/VqtNc5AN0fy9tW+UBwdzZT67ZPi0sUPbO5Gn4I9iWUznGZU2A n5dZk/aFX+NW+hpkNfREUK0X1sBznusRRD8FgCY+fMg9560S5yageIQU5dH1q1hrM9Kw Rzfw== X-Gm-Message-State: AC+VfDyFjF7qPo6GcZa+8cE5WV8WvhxynCylPKPDtNsXbu7rSSNKbij8 xJWqv7w+rfnGt/qnaU0EW5jE4YPPff9bEKpH3dsYQA== X-Google-Smtp-Source: ACHHUZ5lHTyUiE/kl2PsEqYfURKY54833RcnHytNpujvFfEXGhX0B5Iq4FG3i+Dhdx1dzL6ZONw1syDMnVoGChG0jHM= X-Received: by 2002:a17:907:3f18:b0:978:6e73:e837 with SMTP id hq24-20020a1709073f1800b009786e73e837mr8777288ejc.4.1687113171090; Sun, 18 Jun 2023 11:32:51 -0700 (PDT) MIME-Version: 1.0 References: <20230618065744.1363948-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Sun, 18 Jun 2023 11:32:14 -0700 Message-ID: Subject: Re: [RFC PATCH 1/5] mm/mlock: rework mlock_count to use _mapcount for order-0 folios To: Matthew Wilcox Cc: Andrew Morton , Yu Zhao , "Jan Alexander Steffens (heftig)" , Steven Barrett , Brian Geffon , "T.J. Alumbaugh" , Gaosheng Cui , Suren Baghdasaryan , "Liam R. Howlett" , David Hildenbrand , Jason Gunthorpe , Mathieu Desnoyers , David Howells , Hugh Dickins , Greg Thelen , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: D84CE4001B X-Rspam-User: X-Stat-Signature: c5ns6rh9dds13ztoytwxuekhdask6zqs X-Rspamd-Server: rspam03 X-HE-Tag: 1687113172-148526 X-HE-Meta: U2FsdGVkX19CGelXqUSu1gq4xfO1lcCzZgAC4KbPt+50GRhOgzCuvlzB8E4pXFa4izOOnFn3M7Ae3vc6qNVTfhTCnQnY98Px++NoCeCZ7itMHQEViE5KX8piQUKRdEBH50tDQThyT729J3BQcXoL+Hp9KzcylFNxP5WGDEW7SmBodmoJq1h5si2vpMLBIsqTopkL5+6TsqvfpoyTzVftFFM+57uhA/UIByx7xgxy4dwm1e2M/g7mG/bwvE6TlpgcfIbvQiRsAmt/+kGPpzDxTSvF6BzCxjmmzBCwdONg87TtY9sOnOK6MihpMZsDioFcBC1dbpkMi1xJ9QWnE6+trh+HMdmvIx55a69l1F+x5rk65qIohbFxPxWk8QGjAEzjkD2YYaveKhgOpfWCkeC+DquHtAfPawUQPJep9X/SBThyxgTYtfDq37Ydcrijc+fRuftaJJc5Y1Po+OLIq6Bu/DvTthYREN41KK5rDg59mEXeS+cADsE8VJ0KGj8pj3p4aoEH2s8tb5rtl5kn8X5SyB8+btAhGE1ZzwLCmwXpXZhB0QL/N20SJkeBFqkT+NFyhOYkkQohUQMMOlQ5WmTbUmoHvXwqNVkGYobKwrnY3nvS+r6tarivsk9Hh7NXpWOlISV+Ltsz1489OwUbx1ey9Eke9xiTRPo49zg2jKkMubx9iBb3NULcxk4R14ZhBTDwxuyc/rtYJhDwSQgGJ1/Dq8cOYRyG8AzulBs8c9lGLMJIFS1Ud/WxshXYE5nUeN+a9LLVs8663is54mcs5KvG/1KtZaIokpgSwvvG3y/lLtpvfU2Ibs7Ra1nBcl42Xo1bhhoOGEFjzYdRoTHinO+se7I7f1P6pUASTfzKsRKKMa2y8Qqm1U2WLKZ20zvFFgWGF4jOxaVbF/iguAFaCeILM1FGYBkliKv6xFxYoPS1B7ZYMPTXvnY3qw8LmhQyNdPUEVKd9EN9SYOAZBqO6KF XwrLFO7W 529hX6RVps91r4j2m25N/hwNTnowLAj7JpO20rQ/6yOLmjZJw+8ANzj0G08u6x1Liz+JuR8flkP6xLj373LprfnFebkY3RgxquE82gSGI3A68Aacgljxz1Q1sJa5vOrH7Hf2ajcgtDc7U5/1iTLRm4MT0vxci5DQrtBLiZh2v+UP+w8eGt0hxIMYX5XPc8hD9lUxAMoDU0AaY3OVwGUjpj2l28tvFAmuDWzyCZZlEmjSao2BubQtxAgGR0LWaVkiekno3gWOh4MxhGUMcMlUzF9lEGpcfnsfKAUuX39GXqdV8GDBTyHpejQt030aVuL18PrSsTGIy1MYRao/2p464dbJVBA== 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 Sun, Jun 18, 2023 at 4:20=E2=80=AFAM Matthew Wilcox wrote: > > On Sun, Jun 18, 2023 at 06:57:44AM +0000, Yosry Ahmed wrote: > > @@ -337,6 +318,7 @@ struct folio { > > atomic_t _entire_mapcount; > > atomic_t _nr_pages_mapped; > > atomic_t _pincount; > > + atomic_t _mlock_count; > > #ifdef CONFIG_64BIT > > unsigned int _folio_nr_pages; > > #endif > > You can't quite do this. On 32-bt systems (I know, I know ...), > we have: > > offset page 0 page 1 > 0 flags flags > 4 lru head > 8 lru dtor+order > 12 mapping entire_mapcount > 16 index nr_pages_napped > 20 private pincount > 24 mapcount > 28 refcount > > so it actually ends up overlapping page->mapcount on the second page, > which is of course used for counting the number of PTEs which map > that specific page. Ah yeah, of course. In retrospect, it was very silly of me not to notice given that I was modifying the mapcount handling code. Thanks for pointing this out. > > I don't have a scenario where this would matter, but we are quite > careful to only allocate order-2+ large folios, so I'd suggest putting > it in page 2 instead of page 1. Can you point me to the code that does so? > > I should probably add a comment to struct folio warning of this dragon. > I thought the #ifdef CONFIG_64BIT would be enough to warn unwary > passers-by of its presence, but a more explicit sign must be in order. > I saw the CONFIG_64BIT and spent some time trying to figure out why we need it. I added the size of all explicit fields on 32-bit and they were less than 32 bytes, so I was confused. I looked at the commit log with no luck. I should have realized we should not overlay mapcount or refcount. The presence of _mapcount_1/_refcount_1 fields could have helped. Anyway, we can also put it in page 1 inside #ifdef CONFIG_64BIT. We will need a few extra #ifdef's in mm/mlock.c, and I think that's pretty much it. For 32-bit, we can just keep piggybacking on mapcount for all folios, I doubt a huge number of mappings is a concern for 32-bit anyway. I don't have a strong preference.