Re: [patch v8 3/9] sched: set initial value of runnable avg for newforked task

From: Peter Zijlstra
Date: Mon Jun 17 2013 - 09:08:01 EST


On Mon, Jun 17, 2013 at 05:57:50PM +0800, Alex Shi wrote:
> On 06/17/2013 05:21 PM, Peter Zijlstra wrote:
> >> >
> >> > and make forking balancing imbalance since incorrect load_avg_contrib.
> >> >
> >> > Further more, Morten Rasmussen notice some tasks were not launched at
> >> > once after created. So Paul and Peter suggest giving a start value for
> >> > new task runnable avg time same as sched_slice().
> >> >
> >> > Signed-off-by: Alex Shi <alex.shi@xxxxxxxxx>
> >> > Signed-off-by: Paul Turner <pjt@xxxxxxxxxx>
> > Should you all go read: Documentation/SubmittingPatches , or am I
> > somehow confused on the SoB rules?
>
> has this should been right, if Paul had handed in the modified patch as
> he suggested? :)
>
> Sorry for stupid, I still don't know what's SoB rule?

Right, so it depends on who actually wrote the patch; the only case
that's really hard is when a patch is fully co-authored -- agile dev
nonsense like, 4 hands 1 keyboard situation or so.

Typically there's 1 somebody who did most work on a particular patch;
that someone would be Author/From and have first SoB.

If thereafter the patch becomes part of an aggregate work; he who
compiles can add another SoB; possibly with an extra [] line describing
'smallish' changes that were needed to the initial patch to make it fit
the aggregate.

Example:

From: PJT

foo patch implements foo because bar; note the fubar detail.

SoB: PJT
[alex@intel: changed ponies into horses to make it fit]
SoB: Alex

The other case is where a 'simple' modification of the initial patch
simply won't do; you need to change the core idea of the patch or
similar. In this case I've seen things like:

From: Alex

foo patch implements foo because bar; note the fubar detail.

Based-on-patch-by: PJT
SoB: Alex


This isn't actually in the submitting patches document and I'm not sure
it should be; although some clarification for these weird cases might be
useful.


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