* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 21. August 2007 schrieben Sie:
> > could you try the patch below, does it work any better?
>
> I looked again at the scheduler code and things are getting better
> when I run the patch below on top of your patch and with our
> s
Am Dienstag, 21. August 2007 schrieben Sie:
> could you try the patch below, does it work any better?
I looked again at the scheduler code and things are getting better when I run
the patch below on top of your patch and with our sched_clock prototype. I
guess there is a reason why you want rq->
On Tue, 2007-08-21 at 14:21 +0200, Ingo Molnar wrote:
> hm, i think i must have used the wrong terminology, so let me describe
> what i mean, so that we can argue this more efficiently ;-)
Ok, seems we need to be a bit more precise.
> What i call "real time sched_clock()" is a sched_clock() that
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> > but i dont mind your patch either - it's really the architecture's
> > choice how visible it wants to make external load to the task stats
> > of its virtual machines. I think it is more logical to say that 100%
> > CPU time displayed in '
> what do you think about the rq_clock() #ifdef i did in the previous mail
> plus you making sched_clock() virtual? That way you can keep
> scheduler_tick() driven by real-time, although that generally will cause
> artifacts with SMP load-balancing too. (that was true in the past too)
I just ha
On Tue, 2007-08-21 at 13:36 +0200, Ingo Molnar wrote:
> * Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
>
> > > Wouldnt it be more consistent if a virtual box would not show any
> > > dependency on external load? (i.e. it would slow down all of its
> > > internal functionality transparently, wit
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> > Wouldnt it be more consistent if a virtual box would not show any
> > dependency on external load? (i.e. it would slow down all of its
> > internal functionality transparently, without exposing it via /proc.
> > The only way to observe that w
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> > you mean to revert b27f03d4bd? I'd really like to see this fixed for
> > real for s390 + CONFIG_VIRT_CPU_ACCOUNTING=y. (which seems to be the
> > only case affected)
>
> Not a complete re
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> Am Montag, 20. August 2007 schrieb Ingo Molnar:
> > could you send that precise sched_clock() patch? It should be an order
> > of magnitude simpler than the high-precision stime/utime tracking you
> > already do, and it's needed for quality s
Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> you mean to revert b27f03d4bd? I'd really like to see this fixed for
> real for s390 + CONFIG_VIRT_CPU_ACCOUNTING=y. (which seems to be the
> only case affected)
Not a complete revert, but an ifdef-workaround. I wrote this patch last week
and
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > i know there are some incredibly broken (but rare) boxes where the bios
> > will report it only knows C1 and do C2? Is that the case you are
> > referring to, or is there something else too?
>
> There are first a couple of older and not so old (Centa
> i know there are some incredibly broken (but rare) boxes where the bios
> will report it only knows C1 and do C2? Is that the case you are
> referring to, or is there something else too?
There are first a couple of older and not so old (Centaur) chips that
generally stop the TSC in C1.
And a
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> > the 'invariant' i mentioned only covers scheduler behavior, not
> > accounting behavior. Accounting is separate in theory, but coupled in
> > practice now via sum_exec_runtime.
>
> Forgot
Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> the 'invariant' i mentioned only covers scheduler behavior, not
> accounting behavior. Accounting is separate in theory, but coupled in
> practice now via sum_exec_runtime.
Forgot to answer about that: That means that the current design does no
Am Dienstag, 21. August 2007 schrieb Ingo Molnar:
> Wouldnt it be more consistent if a virtual box would not show any
> dependency on external load? (i.e. it would slow down all of its
> internal functionality transparently, without exposing it via /proc. The
> only way to observe that would be
On Tue, 2007-08-21 at 11:34 +0200, Ingo Molnar wrote:
> * Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
>
> > > hm, does on s390 scheduler_tick() get driven in virtual time or in
> > > real time? The very latest scheduler code will enforce a minimum
> > > rate of sched_clock() across two schedul
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 21, 2007 at 09:09:22AM +0200, Ingo Molnar wrote:
> >
> > * Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > > You should just be using idle notifiers instead instead of adding
> > > more and more custom hooks (like NOHZ has already) x86-64 sti
On Tue, Aug 21, 2007 at 09:09:22AM +0200, Ingo Molnar wrote:
>
> * Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > You should just be using idle notifiers instead instead of adding more
> > and more custom hooks (like NOHZ has already) x86-64 still has them
> > and there is a old patch around to ad
Ingo Molnar writes:
> my feeling is that it gives us generally higher-quality scheduling if we
> drive all things scheduler via virtual time. Do you agree with that?
On PowerPC at least, while we can measure virtual time, there is no
hardware facility for getting an interrupt after a certain amo
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> > hm, does on s390 scheduler_tick() get driven in virtual time or in
> > real time? The very latest scheduler code will enforce a minimum
> > rate of sched_clock() across two scheduler_tick() calls (in rc3 and
> > later kernels). If sched_clock
On Tue, 2007-08-21 at 09:00 +0200, Christian Borntraeger wrote:
> Am Montag, 20. August 2007 schrieb Martin Schwidefsky:
> > On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
> > Ok, that would mean that sched_clock can just return the virtual cpu
> > time and the two hooks starts and stops the
On Tue, 2007-08-21 at 10:42 +0200, Ingo Molnar wrote:
> * Christian Borntraeger <[EMAIL PROTECTED]> wrote:
>
> > Am Montag, 20. August 2007 schrieb Ingo Molnar:
> > > could you send that precise sched_clock() patch? It should be an order
> > > of magnitude simpler than the high-precision stime/ut
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> Am Montag, 20. August 2007 schrieb Ingo Molnar:
> > could you send that precise sched_clock() patch? It should be an order
> > of magnitude simpler than the high-precision stime/utime tracking you
> > already do, and it's needed for quality s
Am Montag, 20. August 2007 schrieb Ingo Molnar:
> could you send that precise sched_clock() patch? It should be an order
> of magnitude simpler than the high-precision stime/utime tracking you
> already do, and it's needed for quality scheduling anyway.
I have a question about that. I just playe
Am Montag, 20. August 2007 schrieb Ingo Molnar:
> ok. Just to make it sure wrt. release-management: you said s390
> sched_clock() is currently at least as precise as stime/utime - so this
> would suggest that there is no regression over v2.6.22? Regardless of
On current git s390 has a sched_clo
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> You should just be using idle notifiers instead instead of adding more
> and more custom hooks (like NOHZ has already) x86-64 still has them
> and there is a old patch around to add them to i386.
these are specially placed callbacks that we want to cal
Am Montag, 20. August 2007 schrieb Martin Schwidefsky:
> On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
> Ok, that would mean that sched_clock can just return the virtual cpu
> time and the two hooks starts and stops the idle periods as far as the
> scheduler is concerned. In this case we ca
Ingo Molnar <[EMAIL PROTECTED]> writes:
You should just be using idle notifiers instead instead of adding more
and more custom hooks (like NOHZ has already) x86-64 still has them
and there is a old patch around to add them to i386.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe
Ingo Molnar writes:
> We seem to agree wrt. sched_clock()'s behavior while the virtual CPU is
> busy: sched_clock() very much wants to track virtual time. (real time is
> pretty much meaningless and coupling sched_clock() to real time would
> make the virtual machine's behavior dependent on the
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> > If a virtual CPU is idle then i think the "real = steal, virtual =
> > 0" way of thinking about idle looks a bit unnatural to me - wouldnt
> > it be better to think in terms of "steal = 0, virtual = real" ?
> > Basically a virtual CPU can idl
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
> > For sched_clock()'s behavior while the virtual CPU is idle: my current
> > idea for that is the patch below (a loosely analoguous problem exists
> > with nohz/dynticks): it makes sched_cl
Martin Schwidefsky wrote:
> On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
>> For sched_clock()'s behavior while the virtual CPU is idle: my current
>> idea for that is the patch below (a loosely analoguous problem exists
>> with nohz/dynticks): it makes sched_clock() valid across idle per
On Mon, 2007-08-20 at 20:08 +0200, Ingo Molnar wrote:
> For sched_clock()'s behavior while the virtual CPU is idle: my current
> idea for that is the patch below (a loosely analoguous problem exists
> with nohz/dynticks): it makes sched_clock() valid across idle periods
> too and uses wall-clock
* Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> > could you send that precise sched_clock() patch? It should be an
> > order of magnitude simpler than the high-precision stime/utime
> > tracking you already do, and it's needed for quality scheduling
> > anyway.
>
> Sure if you can explain w
On Mon, 2007-08-20 at 17:45 +0200, Ingo Molnar wrote:
> * Christian Borntraeger <[EMAIL PROTECTED]> wrote:
>
> > 1. Jan could finish his sched_clock implementation for s390 and we
> > would get close to the precise numbers. This would also let CFS make
> > better decisions. [...]
>
> i think t
* Christian Borntraeger <[EMAIL PROTECTED]> wrote:
> 1. Jan could finish his sched_clock implementation for s390 and we
> would get close to the precise numbers. This would also let CFS make
> better decisions. [...]
i think this is the best option and it should give us the same /proc
accurac
Am Dienstag, 14. August 2007 schrieb Linus Torvalds:
> On Tue, 14 Aug 2007, Christian Borntraeger wrote:
> > Hello Ingo,
> Just a fyi: I think Ingo is on vacation this week without any internet
> access, I think he'll be back next Monday.
>
> Linus
Well deserved.
As Martin and Jan
This is a 2nd try with correct email address, sorry for the duplicates.
Am Sonntag, 12. August 2007 schrieb Ingo Molnar:
> Linus, please pull the latest scheduler git tree from:
Hello Ingo,
this is a followup to the discussion in
http://lkml.org/lkml/2007/7/19/538
Since 2.6.12, s390 already do
38 matches
Mail list logo
