Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp5617873pxb; Sun, 7 Nov 2021 16:31:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJw4b7Slnc9y0g+6fRnJ8UR2Mzm+tcVppuvaZvgTrnryzHPsQTRGI6iHiVv7G4bC+4d6NyMQ X-Received: by 2002:a17:906:ce2a:: with SMTP id sd10mr51651730ejb.154.1636331506720; Sun, 07 Nov 2021 16:31:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636331506; cv=none; d=google.com; s=arc-20160816; b=odJTXu0HnSHbBf+WinsH9StKXGU7Si6losJ7w3MLJsBTy03zYOw1k+l8H33s+++9TN H4C765OBDQhKl+nt/wARITiwMZWsn5xkTbxnj6FkkY/mYLvdF9WTDnp4Dv85opYu9TsR G6mpfN4Z3q0Oqs6wOUvs7vkXRcXTbM11JBaPTin0XWKnUjPcd7b0TpW3M+eB3Yo4IbYv nhej573GtfR+znyU76mk6f7UXoN6/H4hwj2l22BrQPBdaawrdK+B4v4v8RztopWJBxgZ FyNYCAEbU3RNLPrVPqB1Ea8a0oZGgOGbKKBpMzBLffaLH6Cd1vm6+dVh60vEYFoonhyy VKdw== 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=x6qDJwFCEM31eDxN9rlVQlXj0fTGNQbXIopORuPZmxY=; b=QqpUNQS3XzIec5kKyqYbyPed9HeuYiuKA6O1c1mGIUwsA4t70KbGwpAEVacBfllhjm VCRKFDtn1P2cRpHPa8h+pnEnSAmv2n2pCq0+unXRyk5Qz+9bO6PkB4sYTWaGwCSxuqSR YCb6MkjsCceUsxG4tTYHJVdFffXF3fYRSiMd8g7ISbIVAx4ugZNJYWaMwEIQwDhikFJQ IY0h7nsMv+tqzHIkO+YMYVTdS0E4IJKfQUrtLw7bR76wzpe89iegiLP0wBQivaaksVPG pJO5EYg+LrtquKH3gEtbroJe3rua2Rgta6YiQE+Dm5zHmoN2q8+cs6i0E4sUiiS8H4Ys WEkw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@posk.io header.s=google header.b=HHq08N71; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dm3si20923749ejc.316.2021.11.07.16.31.23; Sun, 07 Nov 2021 16:31:46 -0800 (PST) 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=@posk.io header.s=google header.b=HHq08N71; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229807AbhKGS35 (ORCPT + 99 others); Sun, 7 Nov 2021 13:29:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231728AbhKGS34 (ORCPT ); Sun, 7 Nov 2021 13:29:56 -0500 Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1851C061714 for ; Sun, 7 Nov 2021 10:27:13 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id v3so27317180uam.10 for ; Sun, 07 Nov 2021 10:27:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posk.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x6qDJwFCEM31eDxN9rlVQlXj0fTGNQbXIopORuPZmxY=; b=HHq08N71FdqLDSBMmVrSxi2iRW5U0RuXPfXSZK2+ZlbELTTKuD4Rvcgmwo8as/5req wZn7JWk2/g4Af0dGyxzXFj1MKwdmqx/PG36+X9A0R3LayClasbxWh1eSztu4IX3dwHSY OwtiJZIIKVG6p11SIa6kjJJv9QkuQsg8GyISsBXFIQG05pmAimsRoGb65PwbVbxcaGbL a3xN9lwMeQ/Xcesx2/Rmtlyyxawge79NNKtRn3xxigZp3stme19KtIjBux+kQEltm0ef gW65S/uUvFg8/zd4ijjMn0ySUfygvg2eDwB7wikDjFJdrMHuKtLUtO2eA8vEq5It6DXy vLag== 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=x6qDJwFCEM31eDxN9rlVQlXj0fTGNQbXIopORuPZmxY=; b=Le1IXLlIbWsKpWxx32fHd5mTmfVy3HPTr31YiH/YVqrS09SdeD7hdcqF5KYy/o9LYd 6aWFQwlffNv6o3riRpvdpOesc5pCUP5ayThW0Uf+2FsJNFkuirJgDSj18+pyqbIMxwQb ewR7L9ku2wIlX5RkQQQmJXf2tWT8CEeth18MXgzqxA35Tohgehm7Wk7dN6Z9vMiSB2mw Rom/KAoET9ry7O7XwoTbRQwpW0IU6vdp+kVpJ3kJ5peG/m3/fdBl2QgLJ7ZzTaq8slbB cDne2dSMKlR7yIJda3LE6xQIR/vS5ZucUScvfSdTXjT6vt72/0OF0u9QoAW9nlzByZXA bqeQ== X-Gm-Message-State: AOAM532ZWuZpM3C+PbpfwfxdkZWPtDBntqJCZ55sdZDTh8yDbIGl1PLM RHan1MC6n18eZQvCM9C/XaRk6qPm1C4Eb78dDTcD+A== X-Received: by 2002:a67:fa0f:: with SMTP id i15mr1303407vsq.16.1636309632812; Sun, 07 Nov 2021 10:27:12 -0800 (PST) MIME-Version: 1.0 References: <20211104195804.83240-1-posk@google.com> <20211104195804.83240-5-posk@google.com> In-Reply-To: From: Peter Oskolkov Date: Sun, 7 Nov 2021 10:27:02 -0800 Message-ID: Subject: Re: [PATCH v0.8 4/6] sched/umcg, lib/umcg: implement libumcg To: Tao Zhou Cc: Peter Zijlstra , Ingo Molnar , Thomas Gleixner , Andrew Morton , Dave Hansen , Andy Lutomirski , linux-mm@kvack.org, Linux Kernel Mailing List , linux-api@vger.kernel.org, Paul Turner , Ben Segall , Peter Oskolkov , Andrei Vagin , Jann Horn , Thierry Delisle Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 7, 2021 at 8:33 AM Tao Zhou wrote: > > On Thu, Nov 04, 2021 at 12:58:02PM -0700, Peter Oskolkov wrote: > > > +/* Update the state variable, set new timestamp. */ > > +static bool umcg_update_state(uint64_t *state, uint64_t *prev, uint64_t next) > > +{ > > + uint64_t prev_ts = (*prev) >> (64 - UMCG_STATE_TIMESTAMP_BITS); > > + struct timespec now; > > + uint64_t next_ts; > > + int res; > > + > > + /* > > + * clock_gettime(CLOCK_MONOTONIC, ...) takes less than 20ns on a > > + * typical Intel processor on average, even when run concurrently, > > + * so the overhead is low enough for most applications. > > + * > > + * If this is still too high, `next_ts = prev_ts + 1` should work > > + * as well. The only real requirement is that the "timestamps" are > > + * uniqueue per thread within a reasonable time frame. > > + */ > > + res = clock_gettime(CLOCK_MONOTONIC, &now); > > + assert(!res); > > + next_ts = (now.tv_sec * NSEC_PER_SEC + now.tv_nsec) >> > > + UMCG_STATE_TIMESTAMP_GRANULARITY; > > + > > + /* Cut higher order bits. */ > > + next_ts &= ((1ULL << UMCG_STATE_TIMESTAMP_BITS) - 1); > > This is the right cut.. The same to the kernel side. Yes, thanks! > > > + > > + if (next_ts == prev_ts) > > + ++next_ts; > > + > > +#ifndef NDEBUG > > + if (prev_ts > next_ts) { > > + fprintf(stderr, "%s: time goes back: prev_ts: %lu " > > + "next_ts: %lu diff: %lu\n", __func__, > > + prev_ts, next_ts, prev_ts - next_ts); > > + } > > +#endif > > + > > + /* Remove old timestamp, if any. */ > > + next &= ((1ULL << (64 - UMCG_STATE_TIMESTAMP_BITS)) - 1); > > + > > + /* Set the new timestamp. */ > > + next |= (next_ts << (64 - UMCG_STATE_TIMESTAMP_BITS)); > > + > > + /* > > + * TODO: review whether memory order below can be weakened to > > + * memory_order_acq_rel for success and memory_order_acquire for > > + * failure. > > + */ > > + return atomic_compare_exchange_strong_explicit(state, prev, next, > > + memory_order_seq_cst, memory_order_seq_cst); > > +} > > + > > > +static void task_unlock(struct umcg_task_tls *task, uint64_t expected_state, > > + uint64_t new_state) > > +{ > > + bool ok; > > + uint64_t next; > > + uint64_t prev = atomic_load_explicit(&task->umcg_task.state_ts, > > + memory_order_acquire); > > + > > + next = ((prev & ~UMCG_TASK_STATE_MASK_FULL) | new_state) & ~UMCG_TF_LOCKED; > > Use UMCG_TASK_STATE_MASK instead and the other state flag can be checked. Why? We want to clear the TF_LOCKED flag and keep every other bit of state, including other state flags (but excluding timestamp). > > All others places that use UMCG_TASK_STATE_MASK_FULL to mask to check > the task state may seems reasonable if the state flag not allowed to > be set when we check that task state, otherwise use UMCG_TASK_STATE_MASK > will be enough. > > Not sure. > > > Thanks, > Tao > > + assert(next != prev); > > + assert((prev & UMCG_TASK_STATE_MASK_FULL & ~UMCG_TF_LOCKED) == expected_state); > > + > > + ok = umcg_update_state(&task->umcg_task.state_ts, &prev, next); > > + assert(ok); > > +}