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 75917C4345F for ; Sat, 27 Apr 2024 04:07:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 059D86B0083; Sat, 27 Apr 2024 00:07:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00A1B6B0085; Sat, 27 Apr 2024 00:06:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3AB96B0087; Sat, 27 Apr 2024 00:06:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C49816B0083 for ; Sat, 27 Apr 2024 00:06:59 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 71E5640974 for ; Sat, 27 Apr 2024 04:06:59 +0000 (UTC) X-FDA: 82053976158.22.3441A79 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf17.hostedemail.com (Postfix) with ESMTP id 9881040006 for ; Sat, 27 Apr 2024 04:06:57 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=S2z1agsE; spf=pass (imf17.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714190817; a=rsa-sha256; cv=none; b=0qBwHB7EfNHKXVtwS3G/b5+4rsFb+RpNF2bZCDIzRVj5wZHsgffz3H3o+EOBe25jpOM9d7 1ev6CsZUIumHt/Ojyb5xjhiSmRqXy5cHU75m7ShFnmYBdPA1js+NHHrvBJh9jjziqO8wLz EQbjpdas5St4Pgt4nAdmZGWxJFPGc0k= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=S2z1agsE; spf=pass (imf17.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714190817; 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=9K/f+dxXYDgieEAmNtvU2lm4Kz1R5O4qgn/yAw0pjEQ=; b=7oAAgTpWu05hr2PVlh/Tyxxl3Yg7Ltguon+DJTGOVQD4KSxPcVst5bUqb0hxCeYvTRIO9E HlqFCm3H5AWR6s3JneB6PD/bMNsHMIvfE0xpuk4LfGAdELKtUeF4ITtKHKFnlRwnQDDwk3 23y33xA/4ada3wWFap9HRx4hZbMA8cg= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-516d6c1e238so3559441e87.2 for ; Fri, 26 Apr 2024 21:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714190816; x=1714795616; darn=kvack.org; 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=9K/f+dxXYDgieEAmNtvU2lm4Kz1R5O4qgn/yAw0pjEQ=; b=S2z1agsEVaFiMXovIgIL5zobZbh/SezzsGSajDvmelRM2Mp8W7m5Z1JPXmtmdDw5jG nv+Is1VIHB2wsyDJrjzWJtY8KMRtZjbZnXMlyjcRpHqR3IV+5YfYn2DQ9O499dCfglqB xuyeWa0tzuN6EL5Z6sjz04Dq/fBP1UAjOHWHl48vKE2WpemVKPVKQCT/xIV8il3e+yvB U4QDmXrBafcHJVVSPktf32wOAEZWspkVU6OuZWYJNv179dYcCfx4xIvu+NoNxmYm/SFi 0anXt9fUVky1WffLCUp7sTPsFHQDl2qCMt23rz4w8bzav829weIEkxAqCNVYhJNK93kD hBVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714190816; x=1714795616; 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=9K/f+dxXYDgieEAmNtvU2lm4Kz1R5O4qgn/yAw0pjEQ=; b=JVr/8LGEwxdrgB1brEYR42MVWUJbHAyOgKuynchXtkXlJ1kxhYBC2W5PcBdaoJ+qex ubG+OY9YYsJ/s8Gg8ttUFp5f12IuvwbGDjyn+h9ObBLnn3KRJ8MDWUV7w+1xRPvwImh6 ZqYiRWrOC0DwrzFxDYrN6ddsqdf7aL/wkSbtb/kxytOhY4F/tp3zMaHMUpC1lEE13BsP tk/ArQ3N2ju2Xo0VZVonUfbsRCgyam4hr8tl+bzGjBzhFNMZ4EjYw4+Ol8EaWwqB2LFz ziKHrMX2fxWPsqGDPlS5aFwFHeqXARqc9kHEXdtC3OEDt+z+bIs92oh0ypsacfKZXt6s 5S+A== X-Forwarded-Encrypted: i=1; AJvYcCXcYB9XmcmIii8AsYZE1Mst2Lbop2Hv0GDNGiuq02NIbE5vvnW7L8uSPI/gIgLzbXAonGXneVAZDMkTxgD/ilkP0nA= X-Gm-Message-State: AOJu0YyrTLHOuNexfmeDhojbA5sn/YL6m9RAfDnade6QoNsMt2DtIi5g ibh+UMGMcbOCucpoqs0srXIXJhFLZvkUDAXgtlw4ugkQVu5+jmtdcP+wME21WITS8zLEsH42kRa qgK7siIr65ind/KrH9yKsUQtoxbU= X-Google-Smtp-Source: AGHT+IGVv1kSk/OSs+CWD9taUY6vf6uhAQkRImQCkL+FjIpFV6QscIoqsROinfXP6kmFjWmz/5iYBS+jwT0y7+ey1VA= X-Received: by 2002:a05:6512:3102:b0:51d:2c37:6c15 with SMTP id n2-20020a056512310200b0051d2c376c15mr85964lfb.8.1714190815422; Fri, 26 Apr 2024 21:06:55 -0700 (PDT) MIME-Version: 1.0 References: <20240426190253.541419-1-zi.yan@sent.com> In-Reply-To: From: Lance Yang Date: Sat, 27 Apr 2024 12:06:43 +0800 Message-ID: Subject: Re: [PATCH v5] mm/rmap: do not add fully unmapped large folio to deferred split list To: David Hildenbrand Cc: Zi Yan , Andrew Morton , linux-mm@kvack.org, "Matthew Wilcox (Oracle)" , Yang Shi , Ryan Roberts , Barry Song <21cnbao@gmail.com>, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: dhejombn6ncpuag6ahr15nziksaak16w X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9881040006 X-HE-Tag: 1714190817-168380 X-HE-Meta: U2FsdGVkX1/RwFqQ+GF4GoGOI78Uji/5A8//nNbe/C5eKMLUcsFjIBZHN3/NSy1F7fxA/SS6lNQ8vbayelx6QW7BPAWzvSMKIpoS6cfXGSvL2AyOhtvjJAxrSMGBXbvPYJuYNnQXY6wVGxvzfA2MKnaCGG1purLB33rNCVmyZGc13nco8vG0w6uKNX2U5M64JiLFgYBV6BIuWDaWBPEsnng+xWyNfs5VZjGvNEfzcvrEcFfdnLm/JWfMolTlfIjdl4+7TDKIPvo8uHgBeFSbxRLswn5AaXauLWxQRtlRdQyMs2ClXms6gLaOIx2c4CzgaGDeyLHpaOK4FUrvkFX9m/owdE51/CKEu3rdXQ08z/s8aX3pT68dj4kzrulv1grRYr7TpE7rLRhDK8scygwuvdCUCE1L/T93/WEeD8Q+gWZy3POftu6/Xj1VT52Hf/LkDvw9m7Tv9VW4kcV3Uz0DTekH9Pw02oQ/DYBKp0JM3+O/ZUQbyILgjO1rW12N8R06y/CsQbdyPRVHOh97i8He6ajwv5ASRKTC+PwuJ2H8gYPNUdPOWz0jOmvhJVHgIf2xGkKXZqSwHPSarQ2i7YM2S2bfIua5iNKDLiIraZjm4JdvSqDvaDd1UaygNEheNtfShrC2waMIckhR/N9E4qA+TuyuO6r05mdL9PA8HmSWry3fueij1nYXb96AeeRH4dr4QBL0u+ADqIfTItXfzLw+xxaxmiYYhUVVXTb/1NwMwCMk7US5iuC4U9M/N6Vt7KcRtyfxnSlsrDspTJYLGQfVVnzTWSfYHCMHnmxgACigt0Cs5lo5mRZRXNwC39tBZ7GBK62nbYklSmMiS5iuZ3bczokN9hXnOHiutZ8SHIHvtSWPq13B7zrtb5rEYxw/2gtQ4cMPcZ7+TwsYhFn+JF/dJg4PLeQvlrtd78Yw1gLdKRURVrljeuBKs8suCPv+dq37fYwxYloPdauBj9GCH/d g4JGR+e7 rFGW+Kz2ReFk1ZnV3us1vFzKLrED6Gn3EBXDyfpMzquBhGZ3ZbEFM8IHQe1uZosg9c+vEKl01RiEztR9RPFblkBR2dmSxBBU2RYf0FRqCsxpU67kmwhTRI5ePtU/xLL+iBFHcMnnMikQnnvbRddQnon974C/tMC1Yty9qIi2qtNae5M9FLgNmlSkfYt8AeLuNX/lQLUiUFjruP8F37+WWIa0wp6jBqsymlVUdDvlkbrl7rGE0XRmtQe6PRJ9QY2MXqlDmUL0leNq/xQH/DqvxF4Iudpowe8lcOdwJ8KOkjohvQoAfo7AmCZ69WvyFa+FXSMeD4fwZwfU5pe0uVjZ8seeXWzDsPY8+18mc/hDCMc/3emY0RYuq/dUz2P9eEhI+io58yeiI2r5zRtDuBSJliEr7cy+SujUse0gJZg2nFb2dFzopdeLuGS7o3g== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000067, 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 Sat, Apr 27, 2024 at 4:16=E2=80=AFAM David Hildenbrand wrote: > > On 26.04.24 21:20, Zi Yan wrote: > > On 26 Apr 2024, at 15:08, David Hildenbrand wrote: [...] > >>> + bool partially_mapped =3D false; [...] > >>> + > >>> + partially_mapped =3D !!nr && !!atomic_read(mapped); > >> > >> Nit: The && should remove the need for both !!. > > > > My impression was that !! is needed to convert from int to bool and I d= o > > find "!!int && !!int" use in the kernel. > > I might be wrong about this, but if you wouldn't write I think you're correct. > > if (!!nr && !!atomic_read(mapped)) > > then > > bool partially_mapped =3D nr && atomic_read(mapped); > > is sufficient. +1 > > && would make sure that the result is either 0 or 1, which > you can store safely in a bool, no matter which underlying type > is used to store that value. > > But I *think* nowdays, the compiler will always handle that > correctly, even without the "&&" (ever since C99 added _Bool). > > Likely, also > > bool partially_mapped =3D nr & atomic_read(mapped); > > Would nowadays work, but looks stupid. > > > Related: https://lkml.org/lkml/2013/8/31/138 > > --- > #include > #include > #include > #include > > volatile uint64_t a =3D 0x8000000000000000ull; > > void main (void) { > printf("uint64_t a =3D a: 0x%" PRIx64 "\n", a); > > int i1 =3D a; > printf("int i1 =3D a: %d\n", i1); > > int i2 =3D !!a; > printf("int i2 =3D !!a: %d\n", i2); > > bool b1 =3D a; > printf("bool b1 =3D a: %d\n", b1); > > bool b2 =3D !!a; > printf("bool b2 =3D !!a: %d\n", b2); > } > --- > $ ./test > uint64_t a =3D a: 0x8000000000000000 > int i1 =3D a: 0 > int i2 =3D !!a: 1 > bool b1 =3D a: 1 > bool b2 =3D !!a: 1 > --- > > Note that if bool would be defined as "int", you would need the !!, other= wise you > would lose information. Agreed. We need to be careful in this case. > > But even for b1, the gcc generates now: > > 40118c: 48 8b 05 7d 2e 00 00 mov 0x2e7d(%rip),%rax #= 404010 > 401193: 48 85 c0 test %rax,%rax > 401196: 0f 95 c0 setne %al > > > My stdbool.h contains > > #define bool _Bool > > And I think C99 added _Bool that makes that work. > > But I didn't read the standard, and it's time for the weekend :) I just read the C99 and found some interesting information as follows: 6.3.1.2 Boolean type When any *scalar value* is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1. 6.2.5 Types 21. Arithmetic types and pointer types are collectively called *scalar types*. Array and structure types are collectively called aggregate typ= es. 6.5.13 Logical AND operator Semantics The && operator shall yield 1 if both of its operands compare unequal t= o 0; otherwise, it yields 0. The result has type int. 6.5.10 Bitwise AND operator Constraints Each of the operands shall have integer type. Semantics The result of the binary & operator is the bitwise AND of the operands (that is, each bit in the result is set if and only if each of the corresponding bits in the converted operands is set). && would ensure that the result is either 0 or 1, as David said, so no worr= ies. We defined partially_mapped as a bool(_Bool). IIUC, "partially_mapped =3D int & int;" would work correctly as well. However, "partially_mapped =3D long & int;" might not. Using && would be nicer as David suggested :p Thanks, Lance > > -- > Cheers, > > David / dhildenb >