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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E801C0044D for ; Wed, 11 Mar 2020 17:23:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6BB4520736 for ; Wed, 11 Mar 2020 17:23:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WqnHMp8B" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6BB4520736 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 799F86B0008; Wed, 11 Mar 2020 13:23:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 749AF6B000C; Wed, 11 Mar 2020 13:23:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 65F646B0010; Wed, 11 Mar 2020 13:23:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4A26E6B0008 for ; Wed, 11 Mar 2020 13:23:00 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EA299181AEF15 for ; Wed, 11 Mar 2020 17:22:59 +0000 (UTC) X-FDA: 76583751678.17.hand96_374016ab2a430 X-HE-Tag: hand96_374016ab2a430 X-Filterd-Recvd-Size: 5131 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf29.hostedemail.com (Postfix) with ESMTP for ; Wed, 11 Mar 2020 17:22:59 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id t26so2717136ios.11 for ; Wed, 11 Mar 2020 10:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kz9eDew/ZsY+v4diWkXlXdS4p76yVXZWXvOZB/zMk68=; b=WqnHMp8BcP5d+0OspBQRnCS2XHLMlwnGA01CUTTl3ygwrqxUzEY6el55VHXRp7H2db Eum1wajWn5KFNGg2oVp6US7rVx0TcX+UF+MnDREYpmv9YdaFUWYtw1jQexEVrJ3+viap GVovGBa+rHn5BaOeiNWd/yUajbQX66D+vRbF+d7uVrKYzjmcq1OkKduCoRj1ZpRC1FGp 6ESxg9Je6NgXbd7J+5oK4VcpgnZ/I0OFphDVgwzbPB5YRLFO4EQddRJlr/YpvY462CtO mNLZdkI294VlR3j5knUQU3l2T+6KdSD7b++EiLN9gLOmrjwz+czm4Is79pUeKWU+06/W Zdrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kz9eDew/ZsY+v4diWkXlXdS4p76yVXZWXvOZB/zMk68=; b=h8X7JZjgF0q641e20Uqxqeck0tFMm+Fp3RgWwQByTwSMl0cqzbxQ+pw0U2L16/vPRh D2LOfNvPnFFhq5PdQB3GwhRUL+B9P7zg4WRLvwnJdSI3B/NqjIRO6sXb3vEUwcFRyAnW HdiQHHDHOwdZymciFqVX6JWLnzOCOOA5BtHjhWdNrehYw6OwjsOoQCdUHc6w+gbCtxLM x3XvVcAk3r/eXBS1xf2qvDoxUfTIqO61x0uzdJ//VwGIVQkYnxuYu7yM3W04HAozcX9X YEnViZqIJ+ASe4sKFwTrdzGgnJxhWlkoZw5mQhYSY8Sbqi6Im2oIJQliaFm2SSPqEG92 dD6g== X-Gm-Message-State: ANhLgQ2UbjI0qnHtMV4AG8dhpNzwVYIue7kzX3b779odamqfHaAwLEox xBeT5VOFzNzjhNwS1vKOS1NgPAWSMdEOcWv2r4Zqi19w X-Google-Smtp-Source: ADFU+vsJp1OxORPrxA19ckVpZpyXLRyqSv5G0KbQK+xGTh4KIm0B1Xam4v1kQ54IWNnOZsExdhW4L46dsJx002V/ksA= X-Received: by 2002:a6b:cd4a:: with SMTP id d71mr3122618iog.5.1583947378700; Wed, 11 Mar 2020 10:22:58 -0700 (PDT) MIME-Version: 1.0 References: <20200310185609.5401-1-willy@infradead.org> <20200310203732.GC22433@bombadil.infradead.org> <20200311131304.GD22433@bombadil.infradead.org> In-Reply-To: <20200311131304.GD22433@bombadil.infradead.org> From: Alexander Duyck Date: Wed, 11 Mar 2020 10:22:47 -0700 Message-ID: Subject: Re: [PATCH] mm: Make PageType more efficient To: Matthew Wilcox Cc: Andrew Morton , Vlastimil Babka , linux-mm Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000673, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Mar 11, 2020 at 6:13 AM Matthew Wilcox wrote: > > On Tue, Mar 10, 2020 at 02:50:50PM -0700, Alexander Duyck wrote: > > On Tue, Mar 10, 2020 at 1:37 PM Matthew Wilcox wrote: > > > > > -#define PageType(page, flag) \ > > > > > - ((page->page_type & (PAGE_TYPE_BASE | flag)) == PAGE_TYPE_BASE) > > > > > - > > > > >From what I can tell this is the only consumer of PAGE_TYPE_BASE. > > Since it is removed you can probably remove that definition as well. > > I _could_ ... I do want to indicate to people that they probably > shouldn't use those bits in order to leave space for overflow and > wraparound of _mapcount. You already have some of this with the check against PAGE_MAPCOUNT_RESERVE. That is guaranteeing the sign bit is set and that at least one of the bits has been cleared as otherwise it would be equal to 128. The bit you aren't enforcing though is the upper 4 bits. It might make sense to just replace the #define with a comment further down that the upper 4 bit are reserved. > > > > > +#define PageType(page, flag) \ > > > > > + (page_has_type(page) && (~page->page_type & flag)) > > > > You can probably spare a cycle or two here by testing for > > "!(page->page_type & flag)". That way you avoid the extra bit flipping > > since the compiler can just handle the result of the AND op as it sees > > fit. > > GCC already knows to do that optimisation; mm/page_alloc.o is identical > (same md5sum) when changing from (~page->page_type & flag) to > !(page->page_type & flag). So it's just a question of which one is > easier for humans to read and reason about. Do you have an opinion > which one you'd like to see? So it looks like Andrew and Ira are kind of thinking the same way I am. Also one other thing that occurred to me is that by breaking it up the way you did I think it might open things up for possible races since the flag and upper bits are being done as two separate checks. It might make sense to just combine this all into one function and use the READ_ONCE macro on the read of the page_type so that you can be guaranteed that the reading of the variable is atomic.