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 9F80CC47DD9 for ; Fri, 22 Mar 2024 13:20:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDF0E6B0082; Fri, 22 Mar 2024 09:20:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8DBC6B0087; Fri, 22 Mar 2024 09:20:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D55366B0088; Fri, 22 Mar 2024 09:20:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id C61BD6B0082 for ; Fri, 22 Mar 2024 09:20:15 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9056F1604FC for ; Fri, 22 Mar 2024 13:20:15 +0000 (UTC) X-FDA: 81924733590.19.AF871AC Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf16.hostedemail.com (Postfix) with ESMTP id E246A180013 for ; Fri, 22 Mar 2024 13:20:11 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=A1YrjZ6q; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of chrisl@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711113612; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rFLLEyoDC6Klc78WY35HOfiOrAc2S9VLoZ5lE02B0rQ=; b=mPPBJB63nEImSXLeaNVefhdnRw28R+PKGXvbGEdesJI9+mUM5qU8nhwDsCGFBPf9oCCvAR 51hZk1AktbJrIMwUPv48SWGa+3ith1rUIbwjd0agfBgcOfEZ2vHa2Q/ZumrV63pIcMxjZR vUo8fmYl/LqpxnE5qw12fFO/fJ2rHhw= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=A1YrjZ6q; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of chrisl@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711113612; a=rsa-sha256; cv=none; b=2mn3km0kvxpsmimAiMcT4U5PN03PS1Jwn+It/Xiif2goKiGfSTJsip3ZSxhk9D6JVWHM8b 7/9IhGbFe+o+/REYx2xfw3meHnTg5Ma3Jtdp7+doUDjN4GF0s0UuUxnTJ+jvqZgUDL6ZAS qNU/gDlBqFpjlXXeLnPZIDa0tossUXw= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 7BD88CE1801 for ; Fri, 22 Mar 2024 13:20:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B14E6C43394 for ; Fri, 22 Mar 2024 13:20:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711113606; bh=prvrAvxH2CImXFxyQ5e6hd6neKkkvJjK1A/VThwiIyE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=A1YrjZ6quDkuYk2hBCU6LJgd4xlX3NeLB45WRL3HJAC88Xd63GtkIjU5lhmIifjyQ ys2MYtHvDInEOuHVRnNedSGnvof/BtYbX1We9nkadEOkRDSUop93Z7r4BvVrEnlFb9 wlt7B4kuitxwkWXQNE7VmRmtpkDDuxy5EOwez5tb+XXjbVR3Co7qx8TShH2A7WFgnZ slwceEenxxaVqmQB1Jj2LvrFtDJ0LxqABg0HQ6DzXe7SQ5MbLy2u+w9l2+7SE5fZMU GZayiLo8pXr5mJUeCpTY57GHAKPca/4RovQuQrbrcQdP9roiRhQZaQlNx72wzrlIUW kYGaC6FFSLWdQ== Received: by mail-il1-f175.google.com with SMTP id e9e14a558f8ab-3678908266dso8793825ab.0 for ; Fri, 22 Mar 2024 06:20:06 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWxgOlQn8WMjHao5bUczLJWyRgIPWWkNLqIQxTH5+p2NBxDeaRXZHrEE5KyOUSUE1hQf4VEjyef1QKxa90N6e3l/zs= X-Gm-Message-State: AOJu0Ywf4Yp/MvQf7s/OyQrrBSwcfaHv8E+LkVzOoNnlG2PPUIC/9hXz kOTREnEMkwGB0rutCBwlUexhW0BJxzIoBSlS7cf7NsX4MYTXkpcdjSCY83Q5nsc0525f3cmUQ63 D8pVNihww9fKjAn17tQazEjX+joITQSXOKxdS X-Google-Smtp-Source: AGHT+IGB2R6wow2zgHKtqMYRQUOZXQD3hm7dQSeNn7YINb3EJhIs4lc91U2CA2bP5HCcYQXPXPtxXwEtC2bpxLD6fkY= X-Received: by 2002:a92:4a0e:0:b0:366:bcbd:ed84 with SMTP id m14-20020a924a0e000000b00366bcbded84mr2669991ilf.15.1711113605975; Fri, 22 Mar 2024 06:20:05 -0700 (PDT) MIME-Version: 1.0 References: <20240311150058.1122862-1-ryan.roberts@arm.com> <20240311150058.1122862-5-ryan.roberts@arm.com> <87jzm751n3.fsf@yhuang6-desk2.ccr.corp.intel.com> <8734skryev.fsf@yhuang6-desk2.ccr.corp.intel.com> <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: <87r0g3q9cz.fsf_-_@yhuang6-desk2.ccr.corp.intel.com> From: Chris Li Date: Fri, 22 Mar 2024 06:19:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Can you help us on memory barrier usage? (was Re: [PATCH v4 4/6] mm: swap: Allow storage of all mTHP orders) To: "Huang, Ying" Cc: "Paul E. McKenney" , Ryan Roberts , Andrew Morton , David Hildenbrand , Matthew Wilcox , Gao Xiang , Yu Zhao , Yang Shi , Michal Hocko , Kefeng Wang , Barry Song <21cnbao@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E246A180013 X-Stat-Signature: xrcww3ofk4jej56zmz3gzirh33ssqe7x X-HE-Tag: 1711113611-539082 X-HE-Meta: U2FsdGVkX1+thSYAprenegOC5MGR6ca8jPpTegtaPhWBqun0w+Bf+tUJ/AVrnYuc250LoYjSjGnSw8UoIZ4A3DRRGu8w4/whc3aYX9P1WBJ9cYaQERvcUIgQw+gXwCZlPx9UJC41MYYCnFoXTYqY7cZhYfiFw2cXgrBGqSVP/TmjyNeFodt+kfi2W8MS8jSkL/KazPR/TsUle1+RVb/xclNImMR5EZOpsOMhv5LVzO5FqgxdYWYpUCy6oUyis7W1Vhc/mp5M4buYsj43M+AJJ4vYzrABpfi7u/g6h0QdxNTO1lAjNpxQFwXp3y24rfXGJT+uRaU6wDvl9L0iLzabisx2PZIBRmgx4Vn6VNJA6zCEfef/6vdpos8yhAqbXQpWngPsFGkzYgVlZoZQ1V522kamG9u5NROWaqR/Q1OxYBqCJfT1bJTZx1zuLowXgIp+2MU3CrSJJrrM6tiCZ6+kZBXLIu8/Tvp/vqt/HL8VIAjka55YQiJ8q2po7cITE6XMcBgc5RzDtoEp0glgcYrPtjpUdsES0zqmfZ5268ZXrH86PZSKOiNTRqI1JQ0pxfAVJSlEDc7yzso2PBH4B2nO3XoMDbzEUYFOPzXX9pVf5L9eZ7x3S7+tclDwJxT3HJelNY50Iw94h2Pb41a1BFk4UcA7slqUGsYVze0ObkaDxEM9XyOjP8c2RIkr2fK4iIKNh7+m/2eQRB4Eg+FSkxhWcD1remldtdQfSE4PGVvYKquFqtVQ+zuHqcpQadyyK7wf3sv37I3pmYBKIu2Fj++JktSBClfKbuHslBHHWgezEBWni0pTRlK23F6HzaD2BISzxlEiOQ6HufJ8H83DcoBYSw3ZVo4fuqh3x91OH0RwFzC+eGBqRHt+tTkJKAUJJZtrn01+5q2BYm56izNTOt5Ok2Ll0ndJxN2ygXO2JkYd1J97uZBvfjS/RjA+1/dbAMyL7AivmcSBlzcgA7pntor 0CgT8/QZ JmSpujBskR9sO8jhmzlLLV7JCewwlkoFtCD4kORowVS2z6LQoKOwbJyfmxJtzy9eN+q45zG1wHndb9TwiYSbk1wYjBztJg9XEJtczGFFW7jnxxKSRf+ghS7uPK+VynGVEX7w49Qxbh0Z8Cpyf6YRyfjG9N4p3FvpUpcAIcI32b4DstoXiHpcLIKcnByVRHsi8CepG8g9PpE9rDTVZmgYNILAPuhxbu/B4s/1dlUxUg6XbW6mu12Q/AgthAXO0ojzpMb7U6XnR2tTI5qQrC8RLFwnRvsDhf7XonXnqEa8qDSwIVM1gV42neWRXAA== 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: List-Subscribe: List-Unsubscribe: Hi Ying, Very interesting question. On Thu, Mar 21, 2024 at 7:40=E2=80=AFPM Huang, Ying = wrote: > > Hi, Paul, > > Can you help us on WRITE_ONCE()/READ_ONCE()/barrier() usage as follows? > For some example kernel code as follows, > > " > unsigned char x[16]; > > void writer(void) > { > memset(x, 1, sizeof(x)); > /* To make memset() take effect ASAP */ > barrier(); > } > > unsigned char reader(int n) > { > return READ_ONCE(x[n]); > } > " > > where, writer() and reader() may be called on 2 CPUs without any lock. > It's acceptable for reader() to read the written value a little later. I am trying to see if your program can convert into a litmus test so the linux memory model tools can answer it for you. Because you allow reader() to read written value a little later, there is nothing the test can verify against. The reader can see both before or after the writer's update, both are valid observations. To make your test example more complete, you need the reader/writer to do more actions to expose the race. For example, " if (READ_ONCE(x[n]) y =3D 1;" Then you can ask the question whether it is possible to observe x[n] =3D=3D 0 and y=3D=3D 1. That might not be the test condition y= ou have in mind, you can get the idea. We want to have a test example that shows the result observable state to indicate the bad things did happen(or not possible). > Our questions are, > > 1. because it's impossible for accessing "unsigned char" to cause > tearing. So, WRITE_ONCE()/READ_ONCE()/barrier() isn't necessary for > correctness, right? We need to define what is the expected behavior outcome to be "correct", possibly including the before and after barrier actions. Chris > > 2. we use barrier() and READ_ONCE() in writer() and reader(), because we > want to make writing take effect ASAP. Is it a good practice? Or it's > a micro-optimization that should be avoided? > > -- > Best Regards, > Huang, Ying >