linux-kernel - Re: sched: per-entity load-tracking

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 9 Oct 2012 11:35:25 -0700
From:	Paul Turner <pjt@...gle.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...e.hu>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	Venki Pallipadi <venki@...gle.com>,
	Ben Segall <bsegall@...gle.com>,
	Mike Galbraith <efault@....de>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Nikunj A Dadhania <nikunj@...ux.vnet.ibm.com>,
	Morten Rasmussen <Morten.Rasmussen@....com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Namhyung Kim <namhyung@...nel.org>
Subject: Re: sched: per-entity load-tracking

On Sat, Oct 6, 2012 at 12:39 AM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Paul Turner <pjt@...gle.com> wrote:
>
>> Peter:
>> The rebase to tip/master made interdiff angry enough that it wasn't
>> producing the right relative diffs for your stack.  Sorry :(
>
> Find below the diff between the two series, using 'quilt
> snapshot' and 'quilt diff --snapshot'.

So what I was looking to generate here were per-patch differences that
Peter could squash into his quilt stack directly.  I typically find
interdiff works quite well for this, with the exception of the
changelog.

>
> One quick stylistic note: instead of putting the
> update_cfs_rq_blocked_load() in the middle of the file, order
> functions naturally so that no prototypes are needed.

This is certainly a principle I agree with, and I'm not gun-shy about
moving things around to reduce this burden :)

However, in this case I think the prototype is preferable as this code
is right in the middle of the 'core' helper functions for fair.c which
naturally live at the top of the file.  Promoting the group scheduling
bits to remove this dependency would place them several hundred lines
down and be counter-productive towards this structure.

However, if you still feel strongly, it can certainly be done.

Thanks!

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/