On Thu, Dec 20, 2012 at 1:09 PM, Stephen Boyd wrote:
> On 11/26/2012 5:08 AM, Jassi Brar wrote:
>> The patchset introduces 64-bit atomic ops, which would need
>> init_atomic64_lock() already called, but that is an initcall made too
>> late. Should we consider calling init_atomic64_lock() sooner in
On 11/26/2012 5:08 AM, Jassi Brar wrote:
> The patchset introduces 64-bit atomic ops, which would need
> init_atomic64_lock() already called, but that is an initcall made too
> late. Should we consider calling init_atomic64_lock() sooner in
> start_kernel()?
>
> As an example of breakage, I see the
Hi Paul,
On Thu, Aug 23, 2012 at 7:44 PM, wrote:
> Hi all,
>
> Please find attached the latest version for CFS load-tracking.
>
> It implements load-tracking on a per-sched_entity (currently SCHED_NORMAL, but
> could be extended to RT as well) basis. This results in a bottom-up
> load-computatio
On Sat, Oct 6, 2012 at 12:39 AM, Ingo Molnar wrote:
>
> * Paul Turner 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'
On Mon, Oct 8, 2012 at 5:14 AM, Peter Zijlstra wrote:
> On Sat, 2012-10-06 at 09:39 +0200, Ingo Molnar wrote:
>
> Thanks Ingo! Paul,
>
>> tip/kernel/sched/fair.c | 28 ++--
>> 1 file changed, 18 insertions(+), 10 deletions(-)
>>
>> Index: tip/kernel/sched/fair.c
>> =
On Sat, 2012-10-06 at 09:39 +0200, Ingo Molnar wrote:
Thanks Ingo! Paul,
> tip/kernel/sched/fair.c | 28 ++--
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> Index: tip/kernel/sched/fair.c
> ===
>
* Paul Turner 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'.
One quick stylistic note: instead
I've rebased this to tip/master and pushed some minor updates (most
notable: rounding down in decay_load).
Tree is at:
http://git.kernel.org/?p=linux/kernel/git/pjt/sched.git;a=summary
(branch: load-tracking)
If you prefer raw patches there's a quilt series at:
http://rs5.risingnet.net/~pjt
On Mon, Sep 24, 2012 at 10:16 AM, Benjamin Segall wrote:
> "Jan H. Schönherr" writes:
>
>> Hi Paul.
>>
>> Am 23.08.2012 16:14, schrieb p...@google.com:
>>> Please find attached the latest version for CFS load-tracking.
>>
>> Originally, I thought, this series also takes care of
>> the leaf-cfs-ru
"Jan H. Schönherr" writes:
> Hi Paul.
>
> Am 23.08.2012 16:14, schrieb p...@google.com:
>> Please find attached the latest version for CFS load-tracking.
>
> Originally, I thought, this series also takes care of
> the leaf-cfs-runqueue ordering issue described here:
>
> http://lkml.org/lkml/2011/
Hi Paul.
Am 23.08.2012 16:14, schrieb p...@google.com:
> Please find attached the latest version for CFS load-tracking.
Originally, I thought, this series also takes care of
the leaf-cfs-runqueue ordering issue described here:
http://lkml.org/lkml/2011/7/18/86
Now, that I had a closer look, I s
Hi all,
I've refreshed the load-tracking branch at:
http://git.kernel.org/?p=linux/kernel/git/pjt/sched.git;a=summary
With the latest rebased version. Similar I've got a quilt export
below to make it easier for people to patch in.
If you prefer raw patches there's a quilt series at:
http:/
Hi all,
Please find attached the latest version for CFS load-tracking.
It implements load-tracking on a per-sched_entity (currently SCHED_NORMAL, but
could be extended to RT as well) basis. This results in a bottom-up
load-computation in which entities contribute to their parents' load, as
oppose
13 matches
Mail list logo
