Tong Li wrote:
Without the global locking, the global synchronization here is simply
ping-ponging a cache line once of while. This doesn't look expensive to
me, but if it does after benchmarking, adjusting sysctl_base_round_slice
can reduce the ping-pong frequency. There might also be a smart
Tong Li wrote:
On Fri, 27 Jul 2007, Chris Snook wrote:
Bill Huey (hui) wrote:
You have to consider the target for this kind of code. There are
applications
where you need something that falls within a constant error bound.
According
to the numbers, the current CFS rebalancing logic doesn't ac
On Fri, 27 Jul 2007, Chris Snook wrote:
Bill Huey (hui) wrote:
You have to consider the target for this kind of code. There are
applications
where you need something that falls within a constant error bound.
According
to the numbers, the current CFS rebalancing logic doesn't achieve that to
a
On Fri, 27 Jul 2007, Chris Snook wrote:
I don't think that achieving a constant error bound is always a good thing.
We all know that fairness has overhead. If I have 3 threads and 2
processors, and I have a choice between fairly giving each thread 1.0 billion
cycles during the next second, or
Bill Huey (hui) wrote:
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
I don't think that achieving a constant error bound is always a good thing.
We all know that fairness has overhead. If I have 3 threads and 2
processors, and I have a choice between fairly giving each thread 1
On Fri, Jul 27, 2007 at 07:36:17PM -0400, Chris Snook wrote:
> I don't think that achieving a constant error bound is always a good thing.
> We all know that fairness has overhead. If I have 3 threads and 2
> processors, and I have a choice between fairly giving each thread 1.0
> billion cycle
Tong Li wrote:
On Fri, 27 Jul 2007, Chris Snook wrote:
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code
to the kernel. I'm a researcher. My intent was to point out that we
have a problem in the scheduler and my dwrr algorithm can potentially
help fix it. Th
On Fri, Jul 27, 2007 at 12:03:28PM -0700, Tong Li wrote:
> Thanks for the interest. Attached is a design doc I wrote several months
> ago (with small modifications). It talks about the two pieces of my design:
> group scheduling and dwrr. The description was based on the original O(1)
> schedule
On Fri, 27 Jul 2007, Chris Snook wrote:
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code to the
kernel. I'm a researcher. My intent was to point out that we have a problem
in the scheduler and my dwrr algorithm can potentially help fix it. The
patch itself w
Tong Li wrote:
I'd like to clarify that I'm not trying to push this particular code to
the kernel. I'm a researcher. My intent was to point out that we have a
problem in the scheduler and my dwrr algorithm can potentially help fix
it. The patch itself was merely a proof-of-concept. I'd be thril
I'd like to clarify that I'm not trying to push this particular code to
the kernel. I'm a researcher. My intent was to point out that we have a
problem in the scheduler and my dwrr algorithm can potentially help fix
it. The patch itself was merely a proof-of-concept. I'd be thrilled if the
algo
On Thu, 2007-07-26 at 23:31 +0200, Ingo Molnar wrote:
> * Tong Li <[EMAIL PROTECTED]> wrote:
>
> > > you need to measure it over longer periods of time. Its not worth
> > > balancing for such a thing in any high-frequency manner. (we'd trash
> > > the cache constantly migrating tasks back and fo
* Tong Li <[EMAIL PROTECTED]> wrote:
> > you need to measure it over longer periods of time. Its not worth
> > balancing for such a thing in any high-frequency manner. (we'd trash
> > the cache constantly migrating tasks back and forth.)
>
> I have some data below, but before that, I'd like to
On Wed, 25 Jul 2007, Ingo Molnar wrote:
* Tong Li <[EMAIL PROTECTED]> wrote:
> Thanks for the patch. It doesn't work well on my 8-way box. Here's the
> output at two different times. It's also changing all the time.
you need to measure it over longer periods of time. Its not worth
balancing f
Li, Tong N wrote:
On Wed, 2007-07-25 at 16:55 -0400, Chris Snook wrote:
Chris Friesen wrote:
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high-ra
On Wed, 2007-07-25 at 16:55 -0400, Chris Snook wrote:
> Chris Friesen wrote:
> > Ingo Molnar wrote:
> >
> >> the 3s is the problem: change that to 60s! We no way want to
> >> over-migrate for SMP fairness, the change i did gives us reasonable
> >> long-term SMP fairness without the need for high
Chris Friesen wrote:
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high-rate rebalancing.
Actually, I do have requirements from our engineering gu
Ingo Molnar wrote:
the 3s is the problem: change that to 60s! We no way want to
over-migrate for SMP fairness, the change i did gives us reasonable
long-term SMP fairness without the need for high-rate rebalancing.
Actually, I do have requirements from our engineering guys for
short-term fai
* Tong Li <[EMAIL PROTECTED]> wrote:
> Thanks for the patch. It doesn't work well on my 8-way box. Here's the
> output at two different times. It's also changing all the time.
you need to measure it over longer periods of time. Its not worth
balancing for such a thing in any high-frequency man
* Li, Tong N <[EMAIL PROTECTED]> wrote:
> The problem I see is that the current load balancing code is quite
> hueristic and can be quite inaccurate sometimes. Its goal is to
> maintain roughly equal load on each core, where load is defined to be
> the sum of the weights of all tasks on a core
On Wed, 2007-07-25 at 14:03 +0200, Ingo Molnar wrote:
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> ---
> include/linux/sched.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux/include/linux/sched.h
> ===
On Wed, 25 Jul 2007, Ingo Molnar wrote:
they now nicely converte to the expected 80% long-term CPU usage.
so, could you please try the patch below, does it work for you too?
Thanks for the patch. It doesn't work well on my 8-way box. Here's the
output at two different times. It's also chang
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > This patch extends CFS to achieve better fairness for SMPs. For
> > example, with 10 tasks (same priority) on 8 CPUs, it enables each task
> > to receive equal CPU time (80%). [...]
>
> hm, CFS should already offer reasonable long-term SMP fairness.
* Tong Li <[EMAIL PROTECTED]> wrote:
> This patch extends CFS to achieve better fairness for SMPs. For
> example, with 10 tasks (same priority) on 8 CPUs, it enables each task
> to receive equal CPU time (80%). [...]
hm, CFS should already offer reasonable long-term SMP fairness. It
certainly
Chris Snook wrote:
A fraction of *each* CPU, or a fraction of *total* CPU? Per-cpu
granularity doesn't make anything more fair.
Well, our current solution uses per-cpu weights, because our vendor
couldn't get the load balancer working accurately enough. Having
per-cpu weights and cpu affin
On Tue, Jul 24, 2007 at 05:22:47PM -0400, Chris Snook wrote:
> Bill Huey (hui) wrote:
> Well, you need enough CPU time to meet your deadlines. You need
> pre-allocated memory, or to be able to guarantee that you can allocate
> memory fast enough to meet your deadlines. This principle extends to
Chris Friesen wrote:
Chris Snook wrote:
I don't think Chris's scenario has much bearing on your patch. What
he wants is to have a task that will always be running, but can't
monopolize either CPU. This is useful for certain realtime workloads,
but as I've said before, realtime requires expli
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
> Chris Friesen wrote:
>> We currently use CKRM on an SMP machine, but the only way we can get away
>> with it is because our main app is affined to one cpu and just about
>> everything else is affined to the other.
>
> If you're not ex
Chris Snook wrote:
I don't think Chris's scenario has much bearing on your patch. What he
wants is to have a task that will always be running, but can't
monopolize either CPU. This is useful for certain realtime workloads,
but as I've said before, realtime requires explicit resource
allocati
Bill Huey (hui) wrote:
On Tue, Jul 24, 2007 at 04:39:47PM -0400, Chris Snook wrote:
Chris Friesen wrote:
We currently use CKRM on an SMP machine, but the only way we can get away
with it is because our main app is affined to one cpu and just about
everything else is affined to the other.
If yo
Chris Snook wrote:
We have another SMP box that would benefit from group scheduling, but
we can't use it because the load balancer is not nearly good enough.
Which scheduler? Have you tried the CFS group scheduler patches?
CKRM as well.
Haven't tried the CFS group scheduler, as we're stuc
Li, Tong N wrote:
On Tue, 2007-07-24 at 16:39 -0400, Chris Snook wrote:
Divining the intentions of the administrator is an AI-complete problem and we're
not going to try to solve that in the kernel. An intelligent administrator
could also allocate 50% of each CPU to a resource group containin
On Tue, 2007-07-24 at 16:39 -0400, Chris Snook wrote:
> Divining the intentions of the administrator is an AI-complete problem and
> we're
> not going to try to solve that in the kernel. An intelligent administrator
> could also allocate 50% of each CPU to a resource group containing all the
Chris Friesen wrote:
Chris Snook wrote:
Concerns aside, I agree that fairness is important, and I'd really
like to see a test case that demonstrates the problem.
One place that might be useful is the case of fairness between resource
groups, where the load balancer needs to consider each gro
Chris Snook wrote:
Concerns aside, I agree that fairness is important, and I'd really like
to see a test case that demonstrates the problem.
One place that might be useful is the case of fairness between resource
groups, where the load balancer needs to consider each group separately.
Now i
Tong Li wrote:
On Mon, 23 Jul 2007, Chris Snook wrote:
This patch is massive overkill. Maybe you're not seeing the overhead
on your 8-way box, but I bet we'd see it on a 4096-way NUMA box with a
partially-RT workload. Do you have any data justifying the need for
this patch?
Doing anything
On Tue, 2007-07-24 at 04:07 -0400, Chris Snook wrote:
> To clarify, I'm not suggesting that the "balance with cpu (x+1)%n only"
> algorithm is the only way to do this. Rather, I'm pointing out that
> even an extremely simple algorithm can give you fair loading when you
> already have CFS manag
On Mon, 23 Jul 2007, Chris Snook wrote:
This patch is massive overkill. Maybe you're not seeing the overhead on your
8-way box, but I bet we'd see it on a 4096-way NUMA box with a partially-RT
workload. Do you have any data justifying the need for this patch?
Doing anything globally is expe
On Mon, Jul 23, 2007 at 03:25:12PM -0600, Chris Friesen wrote:
> Li, Tong N wrote:
> >On the other hand, if locking does
> >become a problem for certain systems/workloads, increasing
> >sysctl_base_round_slice can reduce the locking frequency and alleviate
> >the problem, at the cost of being relat
Chris Snook wrote:
Tong Li wrote:
This patch extends CFS to achieve better fairness for SMPs. For
example, with 10 tasks (same priority) on 8 CPUs, it enables each task
to receive equal CPU time (80%). The code works on top of CFS and
provides SMP fairness at a coarser time grainularity; local
Tong Li wrote:
This patch extends CFS to achieve better fairness for SMPs. For example,
with 10 tasks (same priority) on 8 CPUs, it enables each task to receive
equal CPU time (80%). The code works on top of CFS and provides SMP
fairness at a coarser time grainularity; local on each CPU, it rel
Li, Tong N wrote:
On the other hand, if locking does
become a problem for certain systems/workloads, increasing
sysctl_base_round_slice can reduce the locking frequency and alleviate
the problem, at the cost of being relatively less fair across the CPUs.
If locking does become a problem, it ma
I benchmarked an early version of this code (against 2.6.21) with
SPECjbb, SPEComp, kernbench, etc. on an 8-processor system, and didn't
see any slowdown compared to the stock scheduler. I'll generate the data
again with this version of the code. On the other hand, if locking does
become a problem
Tong Li <[EMAIL PROTECTED]> writes:
> +
> +read_lock_irqsave(&dwrr_highest_lock, flags);
That lock looks like it would bounce between CPUs like crazy.
Did you try any benchmarks on a larger system?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
This patch extends CFS to achieve better fairness for SMPs. For example,
with 10 tasks (same priority) on 8 CPUs, it enables each task to receive
equal CPU time (80%). The code works on top of CFS and provides SMP
fairness at a coarser time grainularity; local on each CPU, it relies on
CFS to p
45 matches
Mail list logo
