> So I should have just deleted all patches, for none of them has a
> changelog.
>
It is my bad to not make changelogs in patches. The v2 has them, but I should
have made them since always.
> So all this cc crap only hooks into and modifies fair.c behaviour. There
> is absolutely no reason it
So I should have just deleted all patches, for none of them has a
changelog.
It is my bad to not make changelogs in patches. The v2 has them, but I should
have made them since always.
So all this cc crap only hooks into and modifies fair.c behaviour. There
is absolutely no reason it should
On Wed, May 07, 2014 at 02:46:37AM +0800, Yuyang Du wrote:
> > The general code structure is an immediate no go. We're not going to
> > bolt on anything like this.
>
> Could you please detail a little bit about general code structure?
So I should have just deleted all patches, for none of them
On Wed, May 07, 2014 at 02:46:37AM +0800, Yuyang Du wrote:
The general code structure is an immediate no go. We're not going to
bolt on anything like this.
Could you please detail a little bit about general code structure?
So I should have just deleted all patches, for none of them has a
> The general code structure is an immediate no go. We're not going to
> bolt on anything like this.
Could you please detail a little bit about general code structure?
Thank you all the same,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
The general code structure is an immediate no go. We're not going to
bolt on anything like this.
Could you please detail a little bit about general code structure?
Thank you all the same,
Yuyang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Mon, May 05, 2014 at 08:02:40AM +0800, Yuyang Du wrote:
> Hi Ingo, PeterZ, Rafael, and others,
The general code structure is an immediate no go. We're not going to
bolt on anything like this.
I've yet to look at the content.
--
To unsubscribe from this list: send the line "unsubscribe
Hi Ingo, PeterZ, Rafael, and others,
The current scheduler’s load balancing is completely work-conserving. In some
workload, generally low CPU utilization but immersed with CPU bursts of
transient tasks, migrating task to engage all available CPUs for
work-conserving can lead to significant
Hi Ingo, PeterZ, Rafael, and others,
The current scheduler’s load balancing is completely work-conserving. In some
workload, generally low CPU utilization but immersed with CPU bursts of
transient tasks, migrating task to engage all available CPUs for
work-conserving can lead to significant
On Mon, May 05, 2014 at 08:02:40AM +0800, Yuyang Du wrote:
Hi Ingo, PeterZ, Rafael, and others,
The general code structure is an immediate no go. We're not going to
bolt on anything like this.
I've yet to look at the content.
--
To unsubscribe from this list: send the line unsubscribe
10 matches
Mail list logo
