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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D21B9C433EF for ; Thu, 28 Oct 2021 04:09:04 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3023B6103C for ; Thu, 28 Oct 2021 04:09:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3023B6103C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5A9056B0071; Thu, 28 Oct 2021 00:09:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 558C36B0072; Thu, 28 Oct 2021 00:09:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4203C6B0073; Thu, 28 Oct 2021 00:09:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 1C0B76B0071 for ; Thu, 28 Oct 2021 00:09:03 -0400 (EDT) Received: from smtpin39.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 8FC7182499A8 for ; Thu, 28 Oct 2021 04:09:02 +0000 (UTC) X-FDA: 78744515724.39.EAB9B9D Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com [209.85.219.180]) by imf21.hostedemail.com (Postfix) with ESMTP id 460FBD036A5F for ; Thu, 28 Oct 2021 04:08:58 +0000 (UTC) Received: by mail-yb1-f180.google.com with SMTP id 131so360546ybc.7 for ; Wed, 27 Oct 2021 21:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6yUHQHi+npTtdXXk5DuMN99wacJ4E9CG46ltzl64228=; b=LTdKGO67Jtzw5+Mnn0yELwzRX3RGMm4YHRaPSISq3WsblH3jMwIZrhcpbR8CE3AvqX vtlCTmihlqAvOTVddnUf33y6YNos+fTc/rxkg2k+Zqe1Ao9rTbFm4AUSGNALP1Oi4Iwl FG0aF4WHwTzEevGHd3OAGEvZ6ajzCwD8U5CHo42tD2zOV0v8Dnb+FzpLZorxejensSRK Z0MCsf6vXDHbAoUN1lM7g7WsUwlVHU1KV1QetqD9qlWyTePAyOSg5aj1Z4/vLw5KToFG oWvZ7PnOLSb82758FfRyf6fG82KPDKWUeZ8Nfw85EpQdesseSq2G0bFbbIm/a6HuqdmY 9hMw== 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; bh=6yUHQHi+npTtdXXk5DuMN99wacJ4E9CG46ltzl64228=; b=doMzyuImu0mK3DfXLNCxUUcZp5AK7QlvoMMczTMes+qscqqUpGb/sHbSQ/8HX45ESI wOAuRD7qNFCy3RTqiC+GMqk+Y3yp1KoGoHKhY2CAthKECPmmk6yU9DCL9D/y+3dHvHLP JbBYk4NsjngJlZHbeFhOhI2+G0UkVOxTzLRMwPP5rYlIK/zScTpEcXJpqccMhUbjrtM/ JvNosHsgQjP/HffhvYKDqBIO4Xj5RoTEjlnhovw0jwvCIORlnfpcjiYs4Yg6XTSg6EN8 vAZXSufmsHAasaruLSFlbPRv363mTQoAxW/UrGLvas8E9xTH3pOKDkWa/85TSwWw0z/0 tUhA== X-Gm-Message-State: AOAM531VQYNkUg4AU2bWKYrEq7B3pmpmwHz6pcUu2TSfZJIRQXj8mzip uvQonWM1j2fAIgqVZCezU0ajPC4fS7QhGg8IU6QV0Q== X-Google-Smtp-Source: ABdhPJw+r345VCUEQFGpfG8g3EemP/2PHcshnTveryovvI3QNoAMM2nb8j9v9wlGZ+D6DgP/z6a+aAhMIjHeqxiDtxk= X-Received: by 2002:a25:d610:: with SMTP id n16mr2080814ybg.208.1635394140512; Wed, 27 Oct 2021 21:09:00 -0700 (PDT) MIME-Version: 1.0 References: <20211026173822.502506-1-pasha.tatashin@soleen.com> <20211026173822.502506-2-pasha.tatashin@soleen.com> In-Reply-To: From: Muchun Song Date: Thu, 28 Oct 2021 12:08:24 +0800 Message-ID: Subject: Re: [RFC 1/8] mm: add overflow and underflow checks for page->_refcount To: Pasha Tatashin Cc: LKML , Linux Memory Management List , linux-m68k@lists.linux-m68k.org, Anshuman Khandual , Matthew Wilcox , Andrew Morton , william.kucharski@oracle.com, Mike Kravetz , Vlastimil Babka , Geert Uytterhoeven , schmitzmic@gmail.com, Steven Rostedt , Ingo Molnar , Johannes Weiner , Roman Gushchin , weixugc@google.com, Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: sr3safkotp9xqsopsonajqez49drq9ji Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=LTdKGO67; spf=pass (imf21.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.180 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com; dmarc=pass (policy=none) header.from=bytedance.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 460FBD036A5F X-HE-Tag: 1635394138-715693 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, Oct 28, 2021 at 2:22 AM Pasha Tatashin wrote: > > > I found some atomic_add/dec are replaced with atomic_add/dec_return, > > I am going to replace -return variants with -fetch variants, potentially -fetch > > > those helpers with return value imply a full memory barrier around it, but > > others without return value do not. Do you have any numbers to show > > the impact? Maybe atomic_add/dec_return_relaxed can help this. > > The generic variant uses arch_cmpxchg() for all atomic variants > without any extra barriers. Therefore, on platforms that use generic > implementations there won't be performance differences except for an > extra branch that checks results when VM_BUG_ON is enabled. > > On x86 the difference between the two is the following > > atomic_add: > lock add %eax,(%rsi) > > atomic_fetch_add: > lock xadd %eax,(%rsi) > > atomic_fetch_add_relaxed: > lock xadd %eax,(%rsi) > > No differences between relaxed and non relaxed variants. However, we Right. There is no difference on x86. Maybe there are differences in other architectures. > used lock xadd instead of lock add. I am not sure if the performance > difference is going to be different. > > Pasha