Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1164343pxb; Wed, 27 Oct 2021 21:10:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySVilmb+w0rI2SkvwxNdBW2v+R4OPz0sXQO8HE6R+l1lZ1GmUYKhHFo4HvqbWyzDuiSIfh X-Received: by 2002:a65:55c5:: with SMTP id k5mr1420162pgs.471.1635394211311; Wed, 27 Oct 2021 21:10:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635394211; cv=none; d=google.com; s=arc-20160816; b=WSGtWIly7mgIR7f0aM7UtrBG/l+JU7nxcl6tYd3quhSUgkQlfbxVWNZCObKfcWUF1B KokiX/uWzkJgf21tKp4p6AuceTFwEEHhy8b8aNunYlFmzmfa9Y1rbdmGt80slvXAcWUY bgitMWuKoN+O3YyMbWU7vleZxny1JB+nWq5qEmc6FIuW69BkF6By+yMeBUjgDMM6daSj 9m92LU1YTplYnFRdjslPezZ4WAcaSwNIIfWK+N56xDX44OPRnZiQo2PUZ9Rr936c2wYg DwybgXHcRF0p5bK6EqZvzEIy5u26tvEdHOW1TbCs0IKryXDD++WCDWvcwLHqckPjLvX5 LxPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=6yUHQHi+npTtdXXk5DuMN99wacJ4E9CG46ltzl64228=; b=PwXxdOgvulp6n5N5CfTm5WdIW5KhdvrbHY1rAeFVyFHOxEvniBNMIFbE1WNXC5Om0E TeuTgv0EHL/ujEWLQpv73bHMCPEq5XHyV7LSjhqkqSsJk+mGFbezJg0c/KliUbEuxU40 ooKrx0evlJtphx6N/Batrw6lpRszreDdysadwOCfIs4WBN3LOlecZwUTXyvovy4zWVs5 0bCQL2C/VWGb0jm6gP2fokD+BOqVZmMc5KSWu4nmxyo/hMCKDfIH+CMyKpowwSy+PhRf POCJsVmmTznvDAfXhpofVBtslahgkrYK6C3fUq7Opk5QJ0FFZJwlQ8YhekyoY3JdmfRM MsSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=LTdKGO67; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s12si748124pjq.3.2021.10.27.21.09.58; Wed, 27 Oct 2021 21:10:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=LTdKGO67; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229488AbhJ1EL2 (ORCPT + 99 others); Thu, 28 Oct 2021 00:11:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229645AbhJ1EL1 (ORCPT ); Thu, 28 Oct 2021 00:11:27 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D9C1C061570 for ; Wed, 27 Oct 2021 21:09:01 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id y80so11801840ybe.12 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=bJ0nIz2JzXmbv/U4go5PGZL14OZCyVjeJ4sEPDPFXzbXnrKIZUanGX524Xf/Vks1YL BoUdNBXa9qMg0lTZr8EjOFBeFk/fVjfFyxxIVWJ8pxj2fNeo1uuS6WbHC59xECxuPtnt i+rgPsAxIbQsFh9u3etYqxkao2Rwa5YoTcFCTGFBUvhVjdy/A+BklbMSeUgetCMGBJF6 JG9rgGSVbnGjlPZe9nwZ0AU4W+FVoA6MXdVpnvKvAqpb4bBFNflbfRCEjj+wqWYfMoZo RtzY/jJjgf3QES2msNkVayhYxFH0/86vswwT/5cZGVAtVKW6P+pKHFiseH2bHx6NHF4/ ufsw== X-Gm-Message-State: AOAM533DsXlqL8wuSgdVd9UKloQvjfs9Hx77DvUUOMJLZHt8IL+7/hvU 7vQf5oA2495oeOry9I8noX+fxtIUVBJCAn41afSTig== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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