Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp5685457ybv; Tue, 18 Feb 2020 02:02:39 -0800 (PST) X-Google-Smtp-Source: APXvYqwKv2HOe+vgJje2eb5U6v51RC/aabF+OPdXONjDj5TgLchlVWEglKL4S6TlRlAy5UJy62pF X-Received: by 2002:aca:45c1:: with SMTP id s184mr722153oia.158.1582020159623; Tue, 18 Feb 2020 02:02:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582020159; cv=none; d=google.com; s=arc-20160816; b=kzDbtr43rmsPBi+I64l810RybyZDber3Hjxl+BEuo6jq4IVgYxaixnNX3cA4GTPhkR gz9oAsAud+meLMdlYgqzHgkIsySpvMovMMIAOA7ER2EizT4Lv1hAgtrIH8CdNgjeDORk jti7kpDrbhjEPI+FCm3R4T98ZxpMvE0GelqBv3Atj2xByu0dKnLHU0AkxPiQ4hwWLepx 9BiAP1YdHsUpWGPkkY1wD+RgEpW08EsdJjrmvhxKexj1qRxkOq8/MCn9Zh1hpXmD/xHX M3CvlYE1C7q2RPr00qNFg97mpdaemFIYtzNo0soAK10Ciz88NFrjuUkqruPl6GqLDxrB +svA== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=eWWc7ug//BSvvkJJb1q4UoLkQIGAixWPEykMFBVSqaQ=; b=Cwnen9P/cdrIh9I1azHpHSJATVJP0RQvkgZKPdaQ0K4PHmVY3yXj5gytUuHbc4p952 T4DFrIYCRBZSVmPytmPjaX12VNdTSp4I30elVnWmdgfTTi2wdJcZbfEEICUCqFHyV/Pp GKNTTHSUH/UBVEGAitfxkXkohs/gvjnJ0qxNgcddTR9s0kADYqjRKcHt8/v6TxvtsoDf 0DJAhSYpApFenApfri6uBb02j5WROFQBk7sAZsuQ/KVs+2s8C0/PIOZOxdknsoT/53dR FMb0CS/BZuntaB2nygmZrYr71durBheqSPQ1GZyptV01nrToqMxdWMSKSsYQjglX0jTa hjGA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n11si1533591otf.36.2020.02.18.02.02.27; Tue, 18 Feb 2020 02:02:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726556AbgBRKBU (ORCPT + 99 others); Tue, 18 Feb 2020 05:01:20 -0500 Received: from foss.arm.com ([217.140.110.172]:48980 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726327AbgBRKBU (ORCPT ); Tue, 18 Feb 2020 05:01:20 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E2F141FB; Tue, 18 Feb 2020 02:01:19 -0800 (PST) Received: from [10.1.195.59] (ifrit.cambridge.arm.com [10.1.195.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 838ED3F6CF; Tue, 18 Feb 2020 02:01:18 -0800 (PST) Subject: Re: [PATCH 1/3] sched/rt: cpupri_find: implement fallback mechanism for !fit case To: Qais Yousef Cc: Ingo Molnar , Peter Zijlstra , Steven Rostedt , Pavan Kondeti , Dietmar Eggemann , Juri Lelli , Vincent Guittot , Ben Segall , Mel Gorman , linux-kernel@vger.kernel.org References: <20200214163949.27850-1-qais.yousef@arm.com> <20200214163949.27850-2-qais.yousef@arm.com> <3feb31bb-3412-b38c-07a3-136433c87e66@arm.com> <20200217233413.pzwod3y4y6tl3ogh@e107158-lin> From: Valentin Schneider Message-ID: <769315c6-5e1c-ad13-5ac2-a50303693ad6@arm.com> Date: Tue, 18 Feb 2020 10:01:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200217233413.pzwod3y4y6tl3ogh@e107158-lin> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/17/20 11:34 PM, Qais Yousef wrote: > On 02/17/20 17:07, Valentin Schneider wrote: >> Just a drive-by comment; could you split that code move into its own patch? >> It'd make the history a bit easier to read IMO. > > Hmm I don't see how it would help the history. > > In large series with big churn splitting helps to facilitate review, but > I don't think reviewing this patch is hard because of creating the new > function. > > And git-blame will have this patch all over the new function, so people who > care to know the reason of the split will land at the right place directly > without any extra level of indirection. > As a git-blame addict I yearn for nice clean splits, and this is a code move plus a new behaviour; having them in the same patch doesn't make for the prettiest diff there is (also helps for review, yadda yadda). That said, I'm not going to argue further over it, I'm barely a tenant in this house. > Thanks > > -- > Qais Yousef >