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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E9A44C77B61 for ; Tue, 25 Apr 2023 14:47:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234125AbjDYOrd (ORCPT ); Tue, 25 Apr 2023 10:47:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234354AbjDYOr3 (ORCPT ); Tue, 25 Apr 2023 10:47:29 -0400 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7AE0510FB for ; Tue, 25 Apr 2023 07:47:27 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-3ef34c49cb9so124461cf.1 for ; Tue, 25 Apr 2023 07:47:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1682434046; x=1685026046; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=A8D4v18sNHWljGTZiD6H+K+hxsItjerFP14Gx+pEDFE=; b=EHKyisgmDwZLRRF5KVNxF1Lb/INxJUVSaCOr9EKPLPM+l+AnYvQFjvMICF+ZVsuAdm P3FMtDM7eIjG+ib85d7EZrGOptwbcAEShezcxQjLzJuYL9qA4DNKr2wtwYDrguflis0E qSDk7tcbRRXYwVmUyX0pHWFpm6uCEPqyR5Eo3NVejoos0mMzX3y5sU9SDrf+H8/799pf ikzwuOysZmLvfUxIhCNgKeoqoCQQyhyzH53zFhQRhcRpWZeRPQOnzcuwSlJuexinyOmN 7A1J0mVraBfXQvg1+uevDdbMsFmDyqHT5ty7BCJlwcTlnE6kEdaaLcEZiWplwP+Ezq8f 50jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682434046; x=1685026046; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=A8D4v18sNHWljGTZiD6H+K+hxsItjerFP14Gx+pEDFE=; b=LVUdoRQYdZr2B67jcBm4olk0I3jlomxRRLw2g3PEvyyZjW+adSq6QW7axNID9ZgVci 7mhGv/nI13IbCfX/fCeXNe/yqglTgTj+PiX/HFddynTvKSYpUb3Y+8b5wQtYCK2BQC3g fGKg+YPW9iR5aOHFIVQuYcozQK21kY+alpRwwYnfhRU5SFOrbZabZ330eeSHv/HM49Lq h6Sc5/7X4Y84QvqTIBXYHLuflyZRQcrgiqHtIF9bgXIFfpRw+6REhtEkLABWCItH35EX mvnyOX2rhth25PRFd8/qiUSY5GobrDafVdi1oHMqn3k3T6wIoyiJGw2a9e50KfGuDrdk oKTw== X-Gm-Message-State: AAQBX9e5u7ELthO9MKddgmvBrO9K6w2ZDQSkYU+3C7jVWwPNsF23E7ir RyKxhsrumFJnqnXMpZKxlCS15QJoihnpxyf1AJUf X-Google-Smtp-Source: AKy350aNaKKPhR5vt5BUrlj3Zf5sTY9IbjFXe9bgH2TRX+pc7tmPdEVpOMOmeoYc3W2FCa7Tng39yDjtHBFfyul8l7I= X-Received: by 2002:a05:622a:15ce:b0:3ef:3083:a437 with SMTP id d14-20020a05622a15ce00b003ef3083a437mr367056qty.18.1682434046495; Tue, 25 Apr 2023 07:47:26 -0700 (PDT) MIME-Version: 1.0 References: <20230411042511.1606592-1-jstultz@google.com> <20230411042511.1606592-9-jstultz@google.com> <20230422104205.GF1214746@hirez.programming.kicks-ass.net> In-Reply-To: <20230422104205.GF1214746@hirez.programming.kicks-ass.net> From: John Stultz Date: Tue, 25 Apr 2023 15:47:14 +0100 Message-ID: Subject: Re: [PATCH v3 08/14] sched: Replace rq->curr access w/ rq_curr(rq) To: Peter Zijlstra Cc: LKML , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Waiman Long , Boqun Feng , "Paul E . McKenney" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Apr 22, 2023 at 11:42=E2=80=AFAM Peter Zijlstra wrote: > > On Tue, Apr 11, 2023 at 04:25:05AM +0000, John Stultz wrote: > > +static inline struct task_struct *rq_curr(struct rq *rq) > > +{ > > + return rq->curr_exec; > > +} > > + > > +static inline struct task_struct *rq_curr_rcu(struct rq *rq) > > +{ > > + return rcu_dereference(rq->curr_exec); > > +} > > + > > +static inline struct task_struct *rq_curr_once(struct rq *rq) > > +{ > > + return READ_ONCE(rq->curr_exec); > > +} > > + > > +static inline void rq_set_curr(struct rq *rq, struct task_struct *task= ) > > +{ > > + rcu_assign_pointer(rq->curr_exec, task); > > +} > > + > > +/* > > + * XXX jstultz: seems like rcu_assign_pointer above would also > > + * work for this, but trying to match usage. > > + */ > > +static inline void rq_set_curr_rcu_init(struct rq *rq, struct task_str= uct *task) > > +{ > > + RCU_INIT_POINTER(rq->curr_exec, task); > > +} > > > +static inline struct task_struct *rq_selected(struct rq *rq) > > +{ > > + return rq->curr_sched; > > +} > > + > > +static inline struct task_struct *rq_selected_rcu(struct rq *rq) > > +{ > > + return rcu_dereference(rq->curr_sched); > > +} > > + > > +static inline struct task_struct *rq_selected_once(struct rq *rq) > > +{ > > + return READ_ONCE(rq->curr_sched); > > +} > > + > > +static inline void rq_set_selected(struct rq *rq, struct task_struct *= t) > > +{ > > + rcu_assign_pointer(rq->curr_sched, t); > > +} > > How is any of that helping? That's just making it harder to read. Heh. So the main reason I added these was so the !CONFIG_PROXY_EXEC case would be able to collapse down cleanly. > Can we please just keep it rq->curr and rq->proxy and stop this wrapper > fettish. So, I could go back and set the rq_curr() back to rq->curr, but it seems like we'd still want the rq_selected() [whatever its named] wrapper to avoid the extra pointer in the task struct when proxy-exec isn't used. Or do you have a different suggestion for this? thanks -john