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 597DFC3ABB2 for ; Mon, 16 Sep 2024 10:13:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A88186B0089; Mon, 16 Sep 2024 06:13:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A37ED6B008A; Mon, 16 Sep 2024 06:13:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D8306B008C; Mon, 16 Sep 2024 06:13:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6F5E96B0089 for ; Mon, 16 Sep 2024 06:13:02 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C3ABA402C7 for ; Mon, 16 Sep 2024 10:13:01 +0000 (UTC) X-FDA: 82570188162.01.1FE5D34 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf09.hostedemail.com (Postfix) with ESMTP id D07D7140013 for ; Mon, 16 Sep 2024 10:12:59 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=v1sVvDod; dkim=pass header.d=linutronix.de header.s=2020e header.b=ft94qdf3; spf=pass (imf09.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726481524; a=rsa-sha256; cv=none; b=tjJLqJ2J36avts/TtdnGqGEUF9qtQCNlm2uqjPMO/cq4k5Hmn52iyv40vJxR5WwYA3MoGP LEQh/EiG1XZpdSHbax1UxtGzEveWL2HPZfsQHqo2KnB7KOkpNF/HZEAE0raQ8IKnFbZJiZ PRN9mj7u/rHqPWcLwkN05WSWeqdFtPQ= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=v1sVvDod; dkim=pass header.d=linutronix.de header.s=2020e header.b=ft94qdf3; spf=pass (imf09.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726481524; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=v3ll6KO8H5UrZC6yCuHnxrKwZc40QeoVwfA712SGpCg=; b=lvHZOOBu3yAqRwon9xa+y1zzclJwqrv/BUXbMVH9dC/pExjbxgmRsAzGlWu6Q2eCK8YVRG TjS4G8j/NiUKMwaUYjc1Otgz0q3/FA7tCvpuTkSFAsQu2jQyuL8AZjfCcR5pSEUAqcZwoB pv0CbeYrurLb2DzBBhaLcb8jDQefw8w= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1726481577; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v3ll6KO8H5UrZC6yCuHnxrKwZc40QeoVwfA712SGpCg=; b=v1sVvDodszPQaC6MYGfaSe4O0YiaY1fze0PmCKJ6c2G23tPz7qhE8S1B1sLtwUgWIXMmak lcl5g5XiApkWPI1SCVyw7s9z1iO9KN6mpCWlZuVUdZluKI8O4fUF6eIdjm1NesbAgwTjm9 L5r8Exaw6kxoLg3DrFsWi8+mp8bsCM3zkFSSojxJ6whDP0q0k1EnEEodbLafdu9xFs6uaz 8eHdofzdFoTnlGmddqeYRaFKXUxsd24x8fzw0LItUenj5KjkqN5heAotraD7Uf01iomULo x3kKNZ67/a7jl0TuyFLafUFm2vFpo2t7LtFrG+RNKJkiP8/m8yTSt9sPqggSzw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1726481577; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=v3ll6KO8H5UrZC6yCuHnxrKwZc40QeoVwfA712SGpCg=; b=ft94qdf3mKKez4Fq6giUKHTG2x5ATRcMmRN9N6Lxg1hlqvpyZTzutygIeaN9KywFwHwHHJ c1DaKC+nUT0MDZDQ== To: Jeff Layton , John Stultz , Stephen Boyd , Alexander Viro , Christian Brauner , Jan Kara , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , Jonathan Corbet , Chandan Babu R , "Darrick J. Wong" , Theodore Ts'o , Andreas Dilger , Chris Mason , Josef Bacik , David Sterba , Hugh Dickins , Andrew Morton , Chuck Lever , Vadim Fedorenko Cc: Randy Dunlap , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-mm@kvack.org, Jeff Layton Subject: Re: [PATCH v8 01/11] timekeeping: move multigrain timestamp floor handling into timekeeper In-Reply-To: <20240914-mgtime-v8-1-5bd872330bed@kernel.org> References: <20240914-mgtime-v8-0-5bd872330bed@kernel.org> <20240914-mgtime-v8-1-5bd872330bed@kernel.org> Date: Mon, 16 Sep 2024 12:12:55 +0200 Message-ID: <87a5g79aag.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: 7mdpbe4rfhhy981foazsek1ybsx88ita X-Rspamd-Queue-Id: D07D7140013 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1726481579-930373 X-HE-Meta: U2FsdGVkX1+tBDDe0E55UnoYCcbtAgWof72PbcsoyvCWmf5apXOxnMnifZMgnrocbgBNRNutyXJIjE5VHesfyPH3CfQTYLGozLbvOjIuuxdRiRRLDUG/4nYOHeAGXyxB7CReJnJQ61PPsfbkdEbSVL0jzp+3uM3OLxL4OgSOWCaUDWRSY+SkR1W8ggrtjZKj1BeVhMGnasuxez1ojWKxuidkAGXK2GfyM+lIUEC31rqnpbABadvaByO68Y+yOJ4U1audkngvxcKyZzuSahj2I2QdxDDfyTTTwb94d/kJ0LE4LdCqsxIcIhaoC7Qz81CDcCp5NYBOTVakz8OBuAQW+a6G2rvoFFFc3eNysSKmhP1eT9AYsupHgFqSpXVa6ePv7FFqdRjZyxC87mUeJEP3Wws7qs1iKtArEmPEbcK+9/HB8LQy61vp+lw+y3KcIcUxVL5qmRaZq7lizzhK4tMb2HGBDa4Cj2XogIguypyeXKuU0HAR5C4eZxdf5fCArsnbQS9PjdMdB3MvTkeiiE/emAts0PDHXxpFKMnAMauB4Yxt7nxhKz4yIQvTd34YHo9YWXSpXEsAWG3nIS0lv24RJTR57q70Y/zEPAHQRrdCF1zuOyxEOeH2U/8u9GiFTYouXbjP5JF2uKKAhbFnxOXs/w4JAgNe8x61gRGo6f/1Sx/0FLDt47ac//pKASYwl/Tn9DrgtaW0h7bCIa2tpn5oTcLWgEF+bHEMMtHBHp4LBiDVX775tGE1viCiX7N5kPDH2M+vLp6WVpLxTLdyqrMQgFPppDbJJvCQnzpQ1Coo2CY8Z+2UCH/f1TuDoBPctmbMpMb5mvD29umCf2lkGH0gIw3j//Ril2XuMO/CzqMPr3IY1FyeavFAvBX+7Frwx/vMW+VZnXE6wRZiA7yg7IXCeJFMQom/Zn5jiJA7WIg8oeVlScf9gW/odi23FdDQFce+S/jbpRAuUOy8RDjd+Wl gDSbnrN4 SG4y599gchtXlmclZyINKVHP6jxnV6tj+tvps52LiY1Gmzyb6sLFq4jeqq8yBfKZnETJA9zB3TZL/aeA7Dfvic2aTh9tEYVZ7rwTCjIHHQCsSxygqWO4B+GHFaN5qHqaYiXt4IBiJUqBYtA9BC9kSUuxqdm9CjqG4Ph25 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: On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote: > For multigrain timestamps, we must keep track of the latest timestamp What is a multgrain timestamp? Can you please describe the concept behind it? I'm not going to chase random documentation or whatever because change logs have to self contained. And again 'we' do nothing. Describe the problem in technical terms and do not impersonate code. > To maximize the window of this occurring when multiple tasks are racing > to update the floor, ktime_get_coarse_real_ts64_mg returns a cookie > value that represents the state of the floor tracking word, and > ktime_get_real_ts64_mg accepts a cookie value that it uses as the "old" > value when calling cmpxchg(). Clearly: > +void ktime_get_real_ts64_mg(struct timespec64 *ts, u64 cookie) Can you please get your act together? > +/** > + * ktime_get_coarse_real_ts64_mg - get later of coarse grained time or floor > + * @ts: timespec64 to be filled > + * > + * Adjust floor to realtime and compare it to the coarse time. Fill > + * @ts with the latest one. This explains nothing. > Note that this is a filesystem-specific > + * interface and should be avoided outside of that context. > + */ > +void ktime_get_coarse_real_ts64_mg(struct timespec64 *ts) > +{ > + struct timekeeper *tk = &tk_core.timekeeper; > + u64 floor = atomic64_read(&mg_floor); > + ktime_t f_real, offset, coarse; > + unsigned int seq; > + > + WARN_ON(timekeeping_suspended); > + > + do { > + seq = read_seqcount_begin(&tk_core.seq); > + *ts = tk_xtime(tk); > + offset = *offsets[TK_OFFS_REAL]; Why this indirection? What's wrong with using tk_core.timekeeper.offs_real directly? > + } while (read_seqcount_retry(&tk_core.seq, seq)); > + > + coarse = timespec64_to_ktime(*ts); > + f_real = ktime_add(floor, offset); How is any of this synchronized against concurrent updates of the floor value or the offset? I'm failing to see anything which keeps this consistent. If this is magically consistent then it wants a big fat comment in the code which explains it. > +void ktime_get_real_ts64_mg(struct timespec64 *ts, u64 cookie) What is this cookie argument for and how does that match the declaration? > +extern void ktime_get_real_ts64_mg(struct timespec64 *ts); This does not even build. > +{ > + struct timekeeper *tk = &tk_core.timekeeper; > + ktime_t old = atomic64_read(&mg_floor); > + ktime_t offset, mono; > + unsigned int seq; > + u64 nsecs; > + > + WARN_ON(timekeeping_suspended); WARN_ON_ONCE() if at all. > + do { > + seq = read_seqcount_begin(&tk_core.seq); > + > + ts->tv_sec = tk->xtime_sec; > + mono = tk->tkr_mono.base; > + nsecs = timekeeping_get_ns(&tk->tkr_mono); > + offset = *offsets[TK_OFFS_REAL]; > + } while (read_seqcount_retry(&tk_core.seq, seq)); > + > + mono = ktime_add_ns(mono, nsecs); > + > + if (atomic64_try_cmpxchg(&mg_floor, &old, mono)) { > + ts->tv_nsec = 0; > + timespec64_add_ns(ts, nsecs); > + } else { > + /* > + * Something has changed mg_floor since "old" was > + * fetched. "old" has now been updated with the > + * current value of mg_floor, so use that to return > + * the current coarse floor value. 'Something has changed' is a truly understandable technical explanation. I'm not going to accept this voodoo which makes everyone scratch his head who wasn't involved in this. Thanks, tglx