Hi Dhaval,
How does this patch (on top of todays sched-devel.git) work for you?
It keeps my laptop nice and spiffy when I run
let i=0; while [ $i -lt 100 ]; do let i+=1; while :; do :; done & done
under a third user (nobody). This generates huge latencies for the nobody
user (up to 1.6s) but
Hi Dhaval,
How does this patch (on top of todays sched-devel.git) work for you?
It keeps my laptop nice and spiffy when I run
let i=0; while [ $i -lt 100 ]; do let i+=1; while :; do :; done done
under a third user (nobody). This generates huge latencies for the nobody
user (up to 1.6s) but
On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
> I know I am missing something, but aren't we trying to reduce latencies
> here?
I guess Peter is referring to the latency in seeing fairness results. In
other words, with single rq approach, you may require more time for the groups
On Wed, 2008-02-13 at 22:07 +0530, Dhaval Giani wrote:
> On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
> > > > On the same lines, I cant understand how we can be seeing 700ms latency
> > > > (below) unless we had: large number of active groups/users and large
> > > > number of
>
On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
> > > On the same lines, I cant understand how we can be seeing 700ms latency
> > > (below) unless we had: large number of active groups/users and large
> > > number of
> > > tasks within each group/user.
> >
> > All I can say it
On Wed, Feb 13, 2008 at 01:51:18PM +0100, Peter Zijlstra wrote:
>
> On Wed, 2008-02-13 at 08:30 +0530, Srivatsa Vaddagiri wrote:
> > On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
> > > Yes, latency isolation is the one thing I had to sacrifice in order to
> > > get the normal
On Wed, 2008-02-13 at 08:30 +0530, Srivatsa Vaddagiri wrote:
> On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
> > Yes, latency isolation is the one thing I had to sacrifice in order to
> > get the normal latencies under control.
>
> Hi Peter,
> I don't have easy solution
On Wed, 2008-02-13 at 08:30 +0530, Srivatsa Vaddagiri wrote:
On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
Yes, latency isolation is the one thing I had to sacrifice in order to
get the normal latencies under control.
Hi Peter,
I don't have easy solution in mind
On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
On the same lines, I cant understand how we can be seeing 700ms latency
(below) unless we had: large number of active groups/users and large
number of
tasks within each group/user.
All I can say it that its trivial to
On Wed, Feb 13, 2008 at 01:51:18PM +0100, Peter Zijlstra wrote:
On Wed, 2008-02-13 at 08:30 +0530, Srivatsa Vaddagiri wrote:
On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
Yes, latency isolation is the one thing I had to sacrifice in order to
get the normal latencies
On Wed, 2008-02-13 at 22:07 +0530, Dhaval Giani wrote:
On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
On the same lines, I cant understand how we can be seeing 700ms latency
(below) unless we had: large number of active groups/users and large
number of
tasks
On Wed, Feb 13, 2008 at 10:04:44PM +0530, Dhaval Giani wrote:
I know I am missing something, but aren't we trying to reduce latencies
here?
I guess Peter is referring to the latency in seeing fairness results. In
other words, with single rq approach, you may require more time for the groups
to
On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
> Yes, latency isolation is the one thing I had to sacrifice in order to
> get the normal latencies under control.
Hi Peter,
I don't have easy solution in mind either to meet both fairness
and latency goals in a acceptable
On Wed, 2008-02-13 at 00:23 +0530, Dhaval Giani wrote:
> Hi Ingo,
>
> I've been running the latest sched-git through some tests. Here is
> essentially what I am doing,
>
> 1. Mount the control group
> 2. Create 3-4 groups
> 3. Start kernbench inside each group
> 4. Run cpu hogs in each group
>
Hi Ingo,
I've been running the latest sched-git through some tests. Here is
essentially what I am doing,
1. Mount the control group
2. Create 3-4 groups
3. Start kernbench inside each group
4. Run cpu hogs in each group
Essentially the idea is to see how the system responds under extreme CPU
Hi Ingo,
I've been running the latest sched-git through some tests. Here is
essentially what I am doing,
1. Mount the control group
2. Create 3-4 groups
3. Start kernbench inside each group
4. Run cpu hogs in each group
Essentially the idea is to see how the system responds under extreme CPU
On Wed, 2008-02-13 at 00:23 +0530, Dhaval Giani wrote:
Hi Ingo,
I've been running the latest sched-git through some tests. Here is
essentially what I am doing,
1. Mount the control group
2. Create 3-4 groups
3. Start kernbench inside each group
4. Run cpu hogs in each group
On Tue, Feb 12, 2008 at 08:40:08PM +0100, Peter Zijlstra wrote:
Yes, latency isolation is the one thing I had to sacrifice in order to
get the normal latencies under control.
Hi Peter,
I don't have easy solution in mind either to meet both fairness
and latency goals in a acceptable way.
18 matches
Mail list logo
