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 5C92AC433EF for ; Thu, 23 Jun 2022 21:52:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C31998E0196; Thu, 23 Jun 2022 17:52:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE17C8E0192; Thu, 23 Jun 2022 17:52:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AA9CB8E0196; Thu, 23 Jun 2022 17:52:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9B97E8E0192 for ; Thu, 23 Jun 2022 17:52:44 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 741BF811A0 for ; Thu, 23 Jun 2022 21:52:44 +0000 (UTC) X-FDA: 79610850648.04.A95214C Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by imf30.hostedemail.com (Postfix) with ESMTP id 0597B80028 for ; Thu, 23 Jun 2022 21:52:43 +0000 (UTC) Received: by mail-pj1-f47.google.com with SMTP id dw10-20020a17090b094a00b001ed00a16eb4so923550pjb.2 for ; Thu, 23 Jun 2022 14:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=WP+rwC4TGDAfQrrpdmxtx5HaFMWvuSkA5tpFa2Z0KTo=; b=FaIYrEPF7pH2Sg//kKmJsf4O808sp8hU3xWztRq7PW/NTqPPLAtvMC+D62zDoo+Hfo nD4lTJVJCNX6DnRqCnafQOpaZ8N3Ie155liv3aGLaVYMelGO1Mt51ztufJGskpU8fqgH soA/5thJgCOY4jOHBZt46Rh5pmOj6zNvlG4mmfvzHKkPscBNoRjStOvA/rY0qDp7PcGE /RPTM4wLwtu067izgHGTSTyu49NPFzY1X6noKkMnKFZzk623WewYhW1yMNqhhGq5xNVU /0m14dFYj73PPdK7f1clf1vXrU0z0O/T7MeJ4hLanIN4KJJk1axvx7cDOqXDjF0as+QH 21vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=WP+rwC4TGDAfQrrpdmxtx5HaFMWvuSkA5tpFa2Z0KTo=; b=ryHAlexgFF9Lno6zkGGivjOg/WOzyO+pA7LvC6HGMiVcJHjydJY5nspGILD6RgezHm CyIx69nX66h8174ketRSUGp/BDtjXkSJDbXTirVKxafbDP4tBtw5pBQnK1zfsKmt87QQ jfZEKE9AYWOyHA1khRdCDtpmMpMnRc3mhu219hKPftYdrNL1FkIB/SJ7tGiPk7Xya9z5 Xp063vLfCtovrvMgTgjxEQ4JqNDLdaW1NusKVOCN30YXpWYVCrjVLcqt5ABbcx2qDPaI IxMweVDZyZEoPZD9KFsVqTw7plFqlpHh+LFGAj9yGHJDSb0pHHDCUMj5iuoRa69z/nOz cQ2g== X-Gm-Message-State: AJIora933JPuiE9V/HyrEqxBwvlED+qv5xCXscmLn04JNRbD38PGYm9Q 1tOmZa+7+NfIV56teydPASIl1g== X-Google-Smtp-Source: AGRyM1uSglzJGxysU1/dykORfD2OPQF8J5jiG2z0akLmO9sFwpadT8seYG0Mf7zVPB0bl/0++f3GGA== X-Received: by 2002:a17:903:110d:b0:168:c610:9a80 with SMTP id n13-20020a170903110d00b00168c6109a80mr40966937plh.12.1656021162711; Thu, 23 Jun 2022 14:52:42 -0700 (PDT) Received: from google.com (123.65.230.35.bc.googleusercontent.com. [35.230.65.123]) by smtp.gmail.com with ESMTPSA id h4-20020a17090adb8400b001ecb28cfbfesm199878pjv.51.2022.06.23.14.52.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 14:52:42 -0700 (PDT) Date: Thu, 23 Jun 2022 21:52:38 +0000 From: Sean Christopherson To: Peter Xu Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Paolo Bonzini , Andrew Morton , David Hildenbrand , "Dr . David Alan Gilbert" , Andrea Arcangeli , Linux MM Mailing List Subject: Re: [PATCH 2/4] kvm: Merge "atomic" and "write" in __gfn_to_pfn_memslot() Message-ID: References: <20220622213656.81546-1-peterx@redhat.com> <20220622213656.81546-3-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656021164; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WP+rwC4TGDAfQrrpdmxtx5HaFMWvuSkA5tpFa2Z0KTo=; b=Wy3HcxdGYxy71aA9S5+EZ7/o9J3DWa0Vq6NntDJ3a9m90ZqueX2UBT5A+2XpX0auL3U0Zs FrnYbrFrmhktkilcA7zZUeQY2znXHJ2SSzXErSk5TOr5O4Q/CCJlNiTNQWZX5sHoDHkHMp uQeMjkaeJjquPawRq18FsCG9eU1x7aA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656021164; a=rsa-sha256; cv=none; b=Uw1Ynb+fAmmzS69RYvXsjbTtLHL2mODUzOfjtSED9rT+r6hHDwEpDYr1jC3eA3TpeJSWs3 ZEEVjZ1mXBObRfeRL5BhoYpoYN+Y2JCfPUZ2R5jTU1rkymAvETDLJz2g9ohcsdSv5zInC5 oqnmZgrfEvrhjIQI0gUrBb7xpWjLMbk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FaIYrEPF; spf=pass (imf30.hostedemail.com: domain of seanjc@google.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=FaIYrEPF; spf=pass (imf30.hostedemail.com: domain of seanjc@google.com designates 209.85.216.47 as permitted sender) smtp.mailfrom=seanjc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0597B80028 X-Stat-Signature: zfi8bqm4ib9hs1uohr9wegfhw16oxeam X-HE-Tag: 1656021163-405665 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 Thu, Jun 23, 2022, Peter Xu wrote: > On Thu, Jun 23, 2022 at 08:29:13PM +0000, Sean Christopherson wrote: > > This is what I came up with for splitting @async into a pure input (no_wait) and > > a return value (KVM_PFN_ERR_NEEDS_IO). > > The attached patch looks good to me. It's just that.. > > [...] > > > kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn, > > - bool atomic, bool *async, bool write_fault, > > + bool atomic, bool no_wait, bool write_fault, > > bool *writable, hva_t *hva) > > .. with this patch on top we'll have 3 booleans already. With the new one > to add separated as suggested then it'll hit 4. > > Let's say one day we'll have that struct, but.. are you sure you think > keeping four booleans around is nicer than having a flag, no matter whether > we'd like to have a struct or not? No. > kvm_pfn_t __gfn_to_pfn_memslot(const struct kvm_memory_slot *slot, gfn_t gfn, > bool atomic, bool no_wait, bool write_fault, > bool interruptible, bool *writable, hva_t *hva); > > What if the booleans goes to 5, 6, or more? > > /me starts to wonder what'll be the magic number that we'll start to think > a bitmask flag will be more lovely here. :) For the number to really matter, it'd have to be comically large, e.g. 100+. This is all on-stack memory, so it's as close to free as can we can get. Overhead in terms of (un)marshalling is likely a wash for flags versus bools. Bools pack in nicely, so until there are a _lot_ of bools, memory is a non-issue. That leaves readability, which isn't dependent on the number so much as it is on the usage, and will be highly subjective based on the final code. In other words, I'm not dead set against flags, but I would like to see a complete cleanup before making a decision. My gut reaction is to use bools, as it makes consumption cleaner in most cases, e.g. if (!(xxx->write_fault || writable)) return false; versus if (!((xxx->flags & KVM_GTP_WRITE) || writable)) return false; but again I'm not going to say never until I actually see the end result.