Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp4253730ybz; Mon, 20 Apr 2020 19:27:40 -0700 (PDT) X-Google-Smtp-Source: APiQypJR3s+H9QuJE2ACVSCK4QBXXBbu8isrmjTgtZy+gdn5uSBdHPSSbIaAG/5pqMdZJoWmbGcq X-Received: by 2002:aa7:c401:: with SMTP id j1mr16530910edq.31.1587436060118; Mon, 20 Apr 2020 19:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587436060; cv=none; d=google.com; s=arc-20160816; b=wOPeypVmC9WR33Tfgl/k+t3u6uw9s+wW7+/5FEb68osJYzv379br+XvG1CM6hxwO1b JDS8QsIy0byEycxNTERdxYf76JJYkEdDZT0vGlKqgnrnGdH3tR2N4A11yLDZsBYNubAu JbEfZcRayCeXFYANj7m/BnN8vQ5rUw4CQikBlFDFy7uc+FZoTnYWFH8fmFdgVRxNeKGW lY9RqZM5Dpg432DY0fEFSvw7yS54WsB9VFqPs6jDPu6yMRPA/mukeCPvSTJ8YG7BpNxV zWJzy8xFwvOE5ZwF+L4XjnTVOaSTf+SuFfw1nW7WPIey4cl7PY5xG+XoMAEVpASYe0nN yluQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=NLGZhRCZAlVixxX56dor4MaCfuofp5xHk3GlParRzPE=; b=pkbbDv6h9IBfftIWICbZRu+9lhJO2WShS3iCumcvx56UfQ6i6+IqdHIgQxM6gd98H7 +yXPReTXyu8RCcrEz350PlMcsg99TGaq3POdTwzevfTMAuI5gY9IVjx8eU4T3ELoU6Ia vF0Erw37uQc1jiC8laSJ4WwVjzTy4CJ+Q0oUn/RrO7h6LWG4PROgeQqranFhRwTT//LQ egfTJ2YQcFkAz2ZdXmXmbZQQZDfn2DK+S9gRhquH909yP7Vj22fUkpzEOPcO8eXydHmf taJWM4s/12WgABjJxQ2El5RCYOCvZzttjWZyXe2jyCjTC+tQEUEZjYBRI21hhzpne3DY 0QoA== ARC-Authentication-Results: i=1; mx.google.com; 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 h15si679373edv.341.2020.04.20.19.27.16; Mon, 20 Apr 2020 19:27:40 -0700 (PDT) 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; 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 S1726847AbgDUCXX (ORCPT + 99 others); Mon, 20 Apr 2020 22:23:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:55796 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726801AbgDUCXW (ORCPT ); Mon, 20 Apr 2020 22:23:22 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 74A5E2082E; Tue, 21 Apr 2020 02:23:21 +0000 (UTC) Date: Mon, 20 Apr 2020 22:23:19 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Valentin Schneider , Chen Yu , linux-kernel@vger.kernel.org, Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman Subject: Re: [PATCH 2/2] sched: Extract the task putting code from pick_next_task() Message-ID: <20200420222319.34f9f646@oasis.local.home> In-Reply-To: <20200420231355.GU2483@worktop.programming.kicks-ass.net> References: <7c1eab789cb4b53ec5f54644c089ce27ea14088a.1587309963.git.yu.c.chen@intel.com> <20200420183232.16b83374@gandalf.local.home> <20200420231355.GU2483@worktop.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 21 Apr 2020 01:13:55 +0200 Peter Zijlstra wrote: > > The 'finish' thing isn't too far from the truth; it's the last thing we > > need to do with the prev task (in terms of sched bookkeeping, I mean) - > > and in Chen's defence ISTR Peter suggested that name. > > > > Seeing as it's a "supercharged" put_prev_task(), I could live with the > > marginally shorter "put_prev_task_balance()". > > What Valentin said; it's the last put we do before picking a new task. > Also, I don't like long names. That said, I'm open to short and > appropriate suggestions. I wont bikeshed this too much. Is the "finish" more appropriate with the other use cases that are coming. I do like that "put_prev_task_balance()" too. -- Steve