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 2F393C433EF for ; Tue, 8 Mar 2022 18:09:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B1AA48D0015; Tue, 8 Mar 2022 13:09:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id ACB198D0001; Tue, 8 Mar 2022 13:09:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 991BE8D0015; Tue, 8 Mar 2022 13:09:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 8AB188D0001 for ; Tue, 8 Mar 2022 13:09:32 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 59C8F1217A8 for ; Tue, 8 Mar 2022 18:09:32 +0000 (UTC) X-FDA: 79222006584.07.E0DDBB3 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf28.hostedemail.com (Postfix) with ESMTP id DEBE8C0004 for ; Tue, 8 Mar 2022 18:09:31 +0000 (UTC) Received: by mail-lj1-f170.google.com with SMTP id l12so26108300ljh.12 for ; Tue, 08 Mar 2022 10:09:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RS1piInEaOeeJ3BDgDddW1T9qJEE9ha7V/8+KCGHJs4=; b=FypS7Blo0qMP7/3LOa6IVn8CAPTMF+izTGzqA3XGVR7D8JIfKdqgYLlYhP86WheDPx nzZcVKR0AoJdgAQDhSO5pxK5/n2u3LQAxftxbH5KrQWPdtILAyU5f673z0muQV/8Nxdj UQjy7jPKMB6hD5+0kStcLme0wEoTcq2zMZ3uQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RS1piInEaOeeJ3BDgDddW1T9qJEE9ha7V/8+KCGHJs4=; b=FCX9V/BiGusmSWw3RvCoKlG7gp4FBqinje6zmsrXejWchxW73rJWbo64KYfEmzQbud z1dBZReNSa3UEOBaVFpnJPH7KIQLC7wgWANNj71nFf81dnEqO/PnEEP9xjMqWFFdcPL8 KTUYdjimoW3a/E/DxyQVEZ65pb3dZ9X4RcKyen4gaZChfEOxujX1m8IkVvZXjLKhaMpG baQjbJ0jPBXkvm7vtgLGyWcot+gWaJVeDOYXU0t8rDsfgsOVtvXK4aUYaWpRBJsv4rCw XwdcqQqYwda/vJeeUuZ9Llg1d4yx0M7Q64VS3JmYWTtjtgH/0a3V7MtMmC5cTPoUdOrG ARcA== X-Gm-Message-State: AOAM532G2ndC5Gi7hxNeWqgovX5zosFTH6zaNjomscUezt70iJxgXQO5 8DKKzssP0KN/3I4yBjJc+mhV76KOhOmcFHl5OU0= X-Google-Smtp-Source: ABdhPJwj8cc5B0vIOF7+krvdlSMbTxJ0tf0q6aMeEAzSfzbJImO8uYgS/TZXpkaoqf1cYGA//hq4RA== X-Received: by 2002:a2e:b8c5:0:b0:247:e1ba:1f7 with SMTP id s5-20020a2eb8c5000000b00247e1ba01f7mr8574268ljp.349.1646762970122; Tue, 08 Mar 2022 10:09:30 -0800 (PST) Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com. [209.85.208.172]) by smtp.gmail.com with ESMTPSA id bu39-20020a05651216a700b004484a8cf5f8sm263049lfb.302.2022.03.08.10.09.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 10:09:28 -0800 (PST) Received: by mail-lj1-f172.google.com with SMTP id u7so26101762ljk.13 for ; Tue, 08 Mar 2022 10:09:27 -0800 (PST) X-Received: by 2002:a2e:924d:0:b0:246:370c:5618 with SMTP id v13-20020a2e924d000000b00246370c5618mr11412286ljg.358.1646762956411; Tue, 08 Mar 2022 10:09:16 -0800 (PST) MIME-Version: 1.0 References: <20220308141437.144919-1-david@redhat.com> <20220308141437.144919-6-david@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 8 Mar 2022 10:09:00 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 05/15] mm/rmap: convert RMAP flags to a proper distinct rmap_t type To: Nadav Amit Cc: David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Liang Zhang , Pedro Gomes , Oded Gabbay , "linux-mm@kvack.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: DEBE8C0004 X-Stat-Signature: 8ox667bscd8o7z58r6rr3i4xkbno1bya X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=FypS7Blo; dmarc=none; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.170 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspamd-Server: rspam03 X-HE-Tag: 1646762971-466938 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 Tue, Mar 8, 2022 at 9:15 AM Nadav Amit wrote: > > It would be much easier to read. The last time I made such a suggestion, > Ingo said "I personally like bitfields in theory =E2=80=A6 [but] older ve= rsions of > GCC did a really poor job of optimizing them.=E2=80=9D Yeah, even not that old versions had serious issues, iirc. Bitfields can look nice, but they have some _serious_ syntax issues. In particular, they are nice when you want to *test* one single field (ie bit in this case), but basically atrociously bad in almost all other circumstances. For example, passing a bitfield aggregate as an argument is just crazy. Oh, you can do it, with syntax like (struct type) { .field1 =3D 1, .field3 =3D 1 } as the argument but when you say "much easier to read" I laugh in your face and call your mother a hamster. And that's ignoring all the issues when you want to combine two bitfields. You can't do it. There is nothing like the binary "or" operator. Again, it's easy to modify *one* field, but taking two bitfields and merging them? Not going to happen. So no. Bitfields have their place, but they are close to useless as "flags" type things that get passed around as arguments, unless you have very very specific and limited use. Linus