Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 4 Apr 2023 09:59:49 +0800
From:   Aaron Lu <aaron.lu@intel.com>
To:     Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] sched: Fix performance regression introduced by
 mm_cid
Message-ID: <20230404015949.GA14939@ziqianlu-desk2>
References: <20230403181342.210896-1-mathieu.desnoyers@efficios.com>
 <230301bb-58db-650d-8eb3-8915151685d1@efficios.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <230301bb-58db-650d-8eb3-8915151685d1@efficios.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?i6JeqnUU+V8dOS1EHCd8XRXqwwMQRBd9yvR0dhGh+HW2MBAFdaEjDgwN+DOc?=
 =?us-ascii?Q?/D/1LCupi0AjZ4GrtgzW+aLcKd/cGSEBAqaMQUUzWMicV/l620dbDaYuv4Be?=
 =?us-ascii?Q?sxeIm9QrqohAVVW6O/04wrn2YhiH4/4hMnKslQCuToX3N+hPeTY4itI5cv6U?=
 =?us-ascii?Q?dzpr2tlTtO3ezj/OVKSsvMAsr8XcQf+yW7oy42FGFGs88yN91AkDd5D8B6Fm?=
 =?us-ascii?Q?H/S4uOOiJa5E8q2Jb8fpiboZVeN+7EiRUkk8oZIDh5C3Vw4920PdhaRx3zJk?=
 =?us-ascii?Q?ZcrcU0RNkNyABRzm37fjEjPYB4nCkNZAnuH9QSqob7ON0scQ0We4ybpAmDBK?=
 =?us-ascii?Q?FxjqFcsdHF3I7dFi9TApxyfAGsb7VDN2Mf/ayAUy8NHdKET+V0OWxEFJGw8y?=
 =?us-ascii?Q?Z9wk7xwUgWdg0ZBoCNzS5dXyyVYIYlj3UKcpnJcXH4aQavnWjxZtIpd8fmM/?=
 =?us-ascii?Q?oi0FGpYyfiOqF+OrXjY373a+1GKWdmlWNvbprmjLk0pD1ydF9Pj1iCBAxelv?=
 =?us-ascii?Q?4wkZUzN7bYFKJjCmAdpfwpjpG3+p68/4P0HS3cqC9qVTA8fXSMRE1oMpbAZu?=
 =?us-ascii?Q?9bSvx+SiIPINIQpEsuW3FUzL0Dd7AsbKgXtj0oWDJU46RzQIHr8foI2Yybya?=
 =?us-ascii?Q?rbAJTZRUKd6sGPrRh8Nw1roHgdrqaWAoOUZnp9gr1lavwiK+8i+yFyk3VsYE?=
 =?us-ascii?Q?pC3nzWlTBOL0k5gbMhvqXxo7lE0+2YHzU097EBmQtMc74vlwNifqL0rPJ/MT?=
 =?us-ascii?Q?TAmuV/B8bTTwgxpiQkeWnkcRfV60mnx8W9QLkwqvmxeCTxNaDOKPk88CECdR?=
 =?us-ascii?Q?te1F9tC0ao4dG7px2uIOzzAuNGDrCi/5srylC/o09CMKmZpTdLtCUNe88nYw?=
 =?us-ascii?Q?LOpirP83vZN4Y0I2XH2pNo2sJRpDl/qLPMAZ6gBUN4+FSK38AOyBOgWxK5tF?=
 =?us-ascii?Q?OSAItOkHDenNTFPI2NP/coJKKq9pcc6ut2gA9tjqJTZpMrVA3AOVVefkaBdS?=
 =?us-ascii?Q?Y8S3PoIRnzQA1nNVkWD0gMvFTUTQNK5l139RqHf0ig/Es62WmrQZu/TYHK2S?=
 =?us-ascii?Q?o2Q3qXxvym6QC4ZUPKqFUV+2Yvz86G/F1Mf9Nb3M3kmxRKowr1fl1gFB14qv?=
 =?us-ascii?Q?KbL7R3XFjia82n6WZl3zIeTZktm1OQ6OLCjX1zva+CPRso9z12YlKhREed1H?=
 =?us-ascii?Q?ABvBiBqBxIfF9iGskvbi8JpRZv6RBYrSkZH+ZF0Ow+OyOPk9wmq2LvYM1ips?=
 =?us-ascii?Q?8YEt8eCWQk2UXFVDiIUC4mt4wPjQQBSCbSKxnVnkR97BpJIaHWPr9CGXgHbI?=
 =?us-ascii?Q?WUbMA3EVI7DiSQlmF15YZp1k+6Utqy8jMrM7kshCtb2FI7LIL2KQXxMfFl1h?=
 =?us-ascii?Q?33k/qh+TR1GjMCuchNMhjgpVjTtww7TdsUd63v8nUlG9ZFVa1C1m6Tjfe5FO?=
 =?us-ascii?Q?YlOEI54YEBOtuO9kIfv5UiRrze5SdnOyM5jXftxSMYYh4E7HMBNUqRqltrlh?=
 =?us-ascii?Q?7lv3fsJMSekjfGhire92svfOwJNM3WsmhLCfJjds74KBSl5yDgwv0MGnNCq2?=
 =?us-ascii?Q?ff9tJTOpTvYOJ+PF4ZgksWxp8iEfLiodJNWoBJfS?=
X-MS-Exchange-CrossTenant-Network-Message-Id: f8bdecd2-5643-46d0-ff2f-08db34b04a05
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3062.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Apr 2023 01:59:56.5979
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: GA5DGNNeVjfllJ5WqxXjS//4Ugh8u3pmrEJTRcrrY3LdjBSkIRelLktJNHh3UWyLapmXZUcEjnSBPdIsyarDVA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4537
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE
        autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Apr 03, 2023 at 08:13:08PM -0400, Mathieu Desnoyers wrote:
> On 2023-04-03 14:13, Mathieu Desnoyers wrote:
> [...]
> > +/*
> > + * Migration to dst cpu. Called with dst_rq lock held.
> > + */
> > +void sched_mm_cid_migrate_to(struct rq *dst_rq, struct task_struct *t, int src_cid)
> > +{
> > +	struct mm_struct *mm = t->mm;
> > +	int dst_cid, *dst_pcpu_cid;
> > +
> > +	lockdep_assert_rq_held(dst_rq);
> > +
> > +	if (!mm || src_cid == -1)
> > +		return;
> > +
> > +	dst_pcpu_cid = per_cpu_ptr(mm->pcpu_cid, cpu_of(dst_rq));
> > +
> > +	/*
> > +	 * If destination cpu cid is greater than the source cpu cid, unset it
> > +	 * so it can be reallocated.
> > +	 */
> > +	dst_cid = *dst_pcpu_cid;
> > +	if (dst_cid == -1 || dst_cid < src_cid)
> 
> Small detail: I plan to change this from "dst_cid < src_cid" to
> "dst_cid  <= src_cid" in my next version of the patch to handle the
> unlikely case where a task would be migrated back and forth between
> two runqueues without being scheduled. It would be possible that the
> task's last_mm_cid is equal to the dst_cid here, in which case it
> would be better to leave the mm's destination cpu cid set.
>

This patch is still good regarding lock contention.
(I applied the above small change while testing)

> > +		return;
> > +	*dst_pcpu_cid = -1;
> > +	/*
> > +	 * Put dst_cid if it is not currently in use, else it will be lazy put
> > +	 * on the next context switch.
> > +	 */
> > +	if (dst_rq->curr->mm != mm)
> > +		__mm_cid_put(mm, dst_cid);
> > +}

Thanks,
Aaron