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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 E701BC5DF60 for ; Thu, 7 Nov 2019 09:22:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 843192166E for ; Thu, 7 Nov 2019 09:22:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Hjk039/U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 843192166E Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D4CC96B0003; Thu, 7 Nov 2019 04:22:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CFD3C6B0006; Thu, 7 Nov 2019 04:22:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BECBD6B0007; Thu, 7 Nov 2019 04:22:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id A909C6B0003 for ; Thu, 7 Nov 2019 04:22:46 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 83379181AEF15 for ; Thu, 7 Nov 2019 09:22:46 +0000 (UTC) X-FDA: 76128941532.27.seed79_52568b2621d12 X-HE-Tag: seed79_52568b2621d12 X-Filterd-Recvd-Size: 7195 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 09:22:45 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id t1so2156295wrv.4 for ; Thu, 07 Nov 2019 01:22:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g42WYJ0OEybpeU+gQazJj3a7osgk2SHPvPw8W1nrUoY=; b=Hjk039/Ury26B3q7f6nr4+nMOedolszS1OkDDPA04nLkxn6AyelQQvmnPzIMipWw8G DWmc4CLn/v5SKGR6WUxD4wIL8g+X6PKfbfRB13keGzp9rv1DTql7mxVUuwAf9AWA/A4m B9qO++d/oBppihRFmK/ALzyk0tcYbu0wpss+gO2GtOI3rSVEXbl4oQdoQqeTmkSU8rL4 HdiW2R1+xDQQTr/9qsnBUWKjS1YXUmx1QaPblVUuQeExH+wztbTtwPirrZQwB/p+4Vi2 Q5cM5NSrPbJgIRq11lIhv8weRpzasmSGHVbf1fs2g/M2rrF8jo2NKOjrEqGDxvhzeFrh ZwLw== 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:content-transfer-encoding; bh=g42WYJ0OEybpeU+gQazJj3a7osgk2SHPvPw8W1nrUoY=; b=DIJyajkW3MRVprc4BuWPhIMjcWIumlX7ZcQaskBr5HsKRGADJAIyqdiKdeAiql0YU0 M5Z8n7dwyhbQFJK2v7WP/EoeaXmgWb9uS9xuZ7Mex3+yogoTuFJiajxk6POXkBPCao5n I0hiNw/PRJ9EocG1GhpmA3WzmBmpks1z4EAy+okK0YuNRchWD8rSg7AkQf9sJAcxX1/J 2AgPyAVhpVo8wi0dAjf7u9WIsu03+o3juNEmLxG81DR0nzdqgT/1/rwVhFy4Z9w/TIqf 2m0wwo1Si2wqv1d+LUjZ5xEJ5dtZIK5mo9vffJsVZkElRPMcEuICY6abAfFbZplmbsVo w/Jw== X-Gm-Message-State: APjAAAW+vMdQq+6CeMEjGHa2oDJ4vL1Hh30hsD02vHaDQjt/Rn8CAprZ pmfKlGCjpg6wJ7fnBsvY2doCpGn1vNemBVcglFsgDw== X-Google-Smtp-Source: APXvYqza7pxHzE5Y+OwH5ngxA3bPRVLA4nopy5j8fyLbA2KPwhr7SCz3H5kfx9ftKIN4uXBMK0CxUd/1XXXnpt1mKxI= X-Received: by 2002:a05:6000:18c:: with SMTP id p12mr1810349wrx.154.1573118563965; Thu, 07 Nov 2019 01:22:43 -0800 (PST) MIME-Version: 1.0 References: <20191030142237.249532-1-glider@google.com> <20191030142237.249532-3-glider@google.com> <20191101055033.GA226263@google.com> <20191107060816.GA93084@google.com> In-Reply-To: From: Alexander Potapenko Date: Thu, 7 Nov 2019 10:22:32 +0100 Message-ID: Subject: Re: [PATCH RFC v2 02/25] stackdepot: prevent Clang from optimizing away stackdepot_memcmp() To: Arnd Bergmann Cc: Sergey Senozhatsky , Vegard Nossum , Dmitry Vyukov , Linux Memory Management List , Al Viro , Andrew Morton , Andrey Ryabinin , Andy Lutomirski , Ard Biesheuvel , Christoph Hellwig , Dmitry Torokhov , Eric Dumazet , Eric Van Hensbergen , Greg Kroah-Hartman , Harry Wentland , Herbert Xu , Ingo Molnar , Jens Axboe , "Martin K . Petersen" , Martin Schwidefsky , "Michael S. Tsirkin" , Michal Simek , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Takashi Iwai , "Theodore Ts'o" , Thomas Gleixner , Wolfram Sang , Vasily Gorbik , Ilya Leoshkevich , Mark Rutland , Matthew Wilcox , Randy Dunlap , Andrey Konovalov , Marco Elver Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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, Nov 7, 2019 at 10:04 AM Arnd Bergmann wrote: > > On Thu, Nov 7, 2019 at 7:08 AM Sergey Senozhatsky > wrote: > > > > On (19/11/06 12:43), Alexander Potapenko wrote: > > > > On (19/10/30 15:22), glider@google.com wrote: > > > > > @@ -163,6 +163,11 @@ int stackdepot_memcmp(const unsigned long *u= 1, const unsigned long *u2, > > > > > unsigned int n) > > > > > { > > > > > for ( ; n-- ; u1++, u2++) { > > > > > + /* > > > > > + * Prevent Clang from replacing this function with = a bcmp() > > > > > + * call. > > > > > + */ > > > > > + barrier(); > > > > > if (*u1 !=3D *u2) > > > > > return 1; > > > > > } > > > > > > > > Would 'volatile' do the trick? > > > It does. I can replace the barrier with a volatile if you think that'= s better. > > > However this'll add a checkpatch warning, as volatiles are discourage= d > > > for synchronization (although in this case there's no synchronization= ) > > > > Yeah, 'volatile' in this case will do what it sort of meant to do - pre= vent > > compiler optimizations. So, like you said, it's not a synchronization i= ssue > > and we don't 'volatile' data structures. > > The normal way to do a volatile access would be > READ_ONCE()/WRITE_ONCE(), but that seems stronger than > the barrier() here. I'd just stick to adding a barrier. I actually like the READ_ONCE idea more, as READ_ONCE is really a documented way to prevent the compiler from merging reads, which is what we want here. I also thought that the original barrier() statement was just a compiler barrier, which didn't introduce any additional CPU instructions. Turns out I was wrong, and barrier() also serves as a memory barrier. This doesn't really matter in this case, because this memcmp function isn't performance-critical (we are preventing Clang from optimizing it, after all). Still, READ_ONCE and WRITE_ONCE might be even cheaper, as they are just relaxed memory accesses implemented using volatile. > > Do you need to do barrier() on every iteration? Does clang behave if > > you do one barrier() instead of 'n' barrier()-s? > > If it does things right, it would make that a single-byte copy plus a cal= l > to bcmp(). I certainly wouldn't want to have an implementation that relie= s > on the compiler making sub-optimal decisions ;-) That's a really good point :) > Arnd --=20 Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Stra=C3=9Fe, 33 80636 M=C3=BCnchen Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg