On 01/04/2008 12:18 PM, john stultz wrote:
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid
On 01/04/2008 12:18 PM, john stultz wrote:
On Thu, 2008-01-03 at 15:52 -0800, Dan Hecht wrote:
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There are at least two
places that make this assumption:
1) The calculation at the end of pit_read()
Looking at pit_read() in arch/x86/kernel/i8253.c, it seems that the PIT
clocksource code assumes that the PIT CH0 is in periodic mode. With
clockevents, this assumption is no longer valid. There are at least two
places that make this assumption:
1) The calculation at the end of pit_read()
On 10/29/2007 04:02 PM, Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden <[EMAIL PROTECTED]> wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and
On 10/29/2007 04:02 PM, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
On Mon, 2007-10-29 at 23:48 +0100, Ingo Molnar wrote:
* Zachary Amsden [EMAIL PROTECTED] wrote:
if it's inaccurate why are you exposing it to the guest then? Native
only uses the TSC if it's safe and
On 03/15/2007 01:14 PM, Rik van Riel wrote:
Dan Hecht wrote:
Yes, the part in the "i.e." above is describing available time. So,
it is essentially is the same definition of stolen time VMI uses:
stolen time == ready to run but not running
available time == running or not re
On 03/15/2007 12:53 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Available time is defined to be (real_time - stolen_time). i.e. time
in which the vcpu is either running or not ready to run [because it is
halted, and nothing is pending]).
Hm, the Xen definition of stolen time is "
On 03/14/2007 02:18 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Sounds good. I don't see this in your patchset you sent yesterday
though; did you add it after sending out those patches?
Yes.
if so, could you forward
On 03/14/2007 02:18 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Sounds good. I don't see this in your patchset you sent yesterday
though; did you add it after sending out those patches?
Yes.
if so, could you forward
On 03/15/2007 12:53 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Available time is defined to be (real_time - stolen_time). i.e. time
in which the vcpu is either running or not ready to run [because it is
halted, and nothing is pending]).
Hm, the Xen definition of stolen time is time VCPU
On 03/15/2007 01:14 PM, Rik van Riel wrote:
Dan Hecht wrote:
Yes, the part in the i.e. above is describing available time. So,
it is essentially is the same definition of stolen time VMI uses:
stolen time == ready to run but not running
available time == running or not ready to run
On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Sounds good. I don't see this in your patchset you sent yesterday
though; did you add it after sending out those patches?
Yes.
if so, could you forward the new patch? does it explicitly prevent
stolen time from getting
How is cpustat->steal used? How does it get out to usermode?
Via /proc/stat, used by modern 'top', maybe other utilities. It is
useful to users who want to see where the time is really going from
inside a guest when running on a (para)virtual machine.
I believe previous set of xen
On 03/13/2007 09:37 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
With your previous definition of work time, would it be that:
monotonic_time == work_time + stolen_time ??
(By monotonic time, I presume you mean monotonic real time.)
Yes, I was just trying to use some consistent
On 03/13/2007 09:37 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
With your previous definition of work time, would it be that:
monotonic_time == work_time + stolen_time ??
(By monotonic time, I presume you mean monotonic real time.)
Yes, I was just trying to use some consistent
How is cpustat-steal used? How does it get out to usermode?
Via /proc/stat, used by modern 'top', maybe other utilities. It is
useful to users who want to see where the time is really going from
inside a guest when running on a (para)virtual machine.
I believe previous set of xen
On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Sounds good. I don't see this in your patchset you sent yesterday
though; did you add it after sending out those patches?
Yes.
if so, could you forward the new patch? does it explicitly prevent
stolen time from getting
On 03/13/2007 02:59 PM, Jeremy Fitzhardinge wrote:
Daniel Walker wrote:
The frequency tracking you mention is done to some extent inside the
timekeeping adjustment functions, but I'm not sure it's totally accurate
for non-timekeeping, and it also tracks things like interrupt latency.
Tracking
On 03/13/2007 02:59 PM, Jeremy Fitzhardinge wrote:
Daniel Walker wrote:
The frequency tracking you mention is done to some extent inside the
timekeeping adjustment functions, but I'm not sure it's totally accurate
for non-timekeeping, and it also tracks things like interrupt latency.
Tracking
On 03/07/2007 03:33 PM, Jeremy Fitzhardinge wrote:
I know the vmi time code has coloured your view here, but I surely hope
it can be got into a better state before posting. I'm biased of course,
but I would rather hope that all these drivers we're talking about will
be as stylistically clean as
On 03/07/2007 02:31 PM, Thomas Gleixner wrote:
Please make these things self contained and not relying on whatever
time_init_hook() contains.
Fixing up the code to do this now
thanks,
Dan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 03/07/2007 12:40 PM, Thomas Gleixner wrote:
Real hardware copes well with relative deltas for the events, even when
it is match register based. I thought long about the support for
absolute expiry values in cycles and decided against them to avoid that
math hackery, which you folks now
On 03/07/2007 01:40 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 13:07 -0800, Jeremy Fitzhardinge wrote:
That would certainly be ideal. We'll look at the xen, vmi, lguest and
kvm paravirtualized time models and see how much they really have in
common. I'm a bit curious about how vmi's
On 03/07/2007 01:21 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 11:49 -0800, Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's ours
for reference (please excuse any formating issues); it's also lean.
We'll send out a proper patch later after some more
On 03/07/2007 01:19 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 13:02 -0800, Dan Hecht wrote:
On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
ours for reference (please excuse any formating issues); it's also
lean. We'll send out a proper
On 03/07/2007 12:11 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
ours for reference (please excuse any formating issues); it's also
lean. We'll send out a proper patch later after some more testing:
So the interrupt side
On 03/07/2007 11:05 AM, Jeremy Fitzhardinge wrote:
James Morris wrote:
It seems to me that it could be useful to have a library of common virtual
time code (entirely separate from pv_ops), to avoid re-implementing some
apparently common requirements, such as: handling TSC frequency changes,
On 03/07/2007 12:15 AM, Ingo Molnar wrote:
On the other hand, Linux's internal details, semantics, approaches are a
lot more ad-hoc and alot more affected by changes in the hardware
environment - that's why i'd not like to see some external ABI
constraint limit aspects of those internals.
On 03/07/2007 12:15 AM, Ingo Molnar wrote:
On the other hand, Linux's internal details, semantics, approaches are a
lot more ad-hoc and alot more affected by changes in the hardware
environment - that's why i'd not like to see some external ABI
constraint limit aspects of those internals.
On 03/07/2007 11:05 AM, Jeremy Fitzhardinge wrote:
James Morris wrote:
It seems to me that it could be useful to have a library of common virtual
time code (entirely separate from pv_ops), to avoid re-implementing some
apparently common requirements, such as: handling TSC frequency changes,
On 03/07/2007 12:11 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
ours for reference (please excuse any formating issues); it's also
lean. We'll send out a proper patch later after some more testing:
So the interrupt side
On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
ours for reference (please excuse any formating issues); it's also
lean. We'll send out a proper
On 03/07/2007 01:19 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 13:02 -0800, Dan Hecht wrote:
On 03/07/2007 12:57 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 12:11 -0800, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's
On 03/07/2007 01:40 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 13:07 -0800, Jeremy Fitzhardinge wrote:
That would certainly be ideal. We'll look at the xen, vmi, lguest and
kvm paravirtualized time models and see how much they really have in
common. I'm a bit curious about how vmi's
On 03/07/2007 01:21 PM, Thomas Gleixner wrote:
On Wed, 2007-03-07 at 11:49 -0800, Dan Hecht wrote:
Jeremy, I saw you sent out the Xen version earlier, thanks. Here's ours
for reference (please excuse any formating issues); it's also lean.
We'll send out a proper patch later after some more
On 03/07/2007 12:40 PM, Thomas Gleixner wrote:
Real hardware copes well with relative deltas for the events, even when
it is match register based. I thought long about the support for
absolute expiry values in cycles and decided against them to avoid that
math hackery, which you folks now
On 03/07/2007 02:31 PM, Thomas Gleixner wrote:
Please make these things self contained and not relying on whatever
time_init_hook() contains.
Fixing up the code to do this now
thanks,
Dan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On 03/07/2007 03:33 PM, Jeremy Fitzhardinge wrote:
I know the vmi time code has coloured your view here, but I surely hope
it can be got into a better state before posting. I'm biased of course,
but I would rather hope that all these drivers we're talking about will
be as stylistically clean as
On 03/06/2007 05:18 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:53 -0800, Dan Hecht wrote:
Ooops. I completely forgot, that you get the absolute expiry time
already in ktime_t format (nanoseconds) when dev->set_next_event() is
called.
dev->next_event = expires;
is done
On 03/06/2007 05:22 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:42 -0800, Dan Hecht wrote:
accounting would be wrong. Instead, we should allow the
tick_sched_timer in cases (c) and (d) to have runtime configurable
period, and then scale the time value accordingly before passing
On 03/06/2007 04:49 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:35 -0800, Dan Hecht wrote:
There is no problem for realtime uses, as the reprogramming path is
running with local interrupts disabled. I can see the point for paravirt
and I'm not opposed to change / expand the interface
On 03/06/2007 03:53 PM, Thomas Gleixner wrote:
2) Virtual interrupts have a relatively high overhead as compared with
native interrupts. So, in vmitime, we wanted to be able to lower the
timer interrupt rate at runtime, even if HZ is a compile time constant
(and set to something high, like
On 03/06/2007 04:24 PM, Jeremy Fitzhardinge wrote:
Thomas Gleixner wrote:
3) clockevent set_next_event interface is suboptimal for paravirt (and
probably realtime-ish uses). The problem is that the expiry is passed
as a relative time. On paravirt, an arbitrary amount of (stolen) time
may
On 03/06/2007 02:21 PM, Andi Kleen wrote:
I believe this was just a quick fix in response to Ingo breaking the VMI
build yesterday by disabling NO_IDLE_HZ on us. There is no technical
reason why NO_IDLE_HZ=y can't coexist with NO_HZ.
Well it's nasty that you force NO_IDLE_HZ on all of
On 03/06/2007 02:59 AM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 00:55 -0800, Zachary Amsden wrote:
a proper CE device also has the added bonus of making high-res timers
guests work automatically. It should be simple: just pass it through to
your hypervisor, a hyper-CE-device, like a
On 03/06/2007 02:59 AM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 00:55 -0800, Zachary Amsden wrote:
a proper CE device also has the added bonus of making high-res timers
guests work automatically. It should be simple: just pass it through to
your hypervisor, a hyper-CE-device, like a
On 03/06/2007 02:21 PM, Andi Kleen wrote:
I believe this was just a quick fix in response to Ingo breaking the VMI
build yesterday by disabling NO_IDLE_HZ on us. There is no technical
reason why NO_IDLE_HZ=y can't coexist with NO_HZ.
Well it's nasty that you force NO_IDLE_HZ on all of
On 03/06/2007 04:24 PM, Jeremy Fitzhardinge wrote:
Thomas Gleixner wrote:
3) clockevent set_next_event interface is suboptimal for paravirt (and
probably realtime-ish uses). The problem is that the expiry is passed
as a relative time. On paravirt, an arbitrary amount of (stolen) time
may
On 03/06/2007 03:53 PM, Thomas Gleixner wrote:
2) Virtual interrupts have a relatively high overhead as compared with
native interrupts. So, in vmitime, we wanted to be able to lower the
timer interrupt rate at runtime, even if HZ is a compile time constant
(and set to something high, like
On 03/06/2007 04:49 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:35 -0800, Dan Hecht wrote:
There is no problem for realtime uses, as the reprogramming path is
running with local interrupts disabled. I can see the point for paravirt
and I'm not opposed to change / expand the interface
On 03/06/2007 05:22 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:42 -0800, Dan Hecht wrote:
accounting would be wrong. Instead, we should allow the
tick_sched_timer in cases (c) and (d) to have runtime configurable
period, and then scale the time value accordingly before passing
On 03/06/2007 05:18 PM, Thomas Gleixner wrote:
On Tue, 2007-03-06 at 16:53 -0800, Dan Hecht wrote:
Ooops. I completely forgot, that you get the absolute expiry time
already in ktime_t format (nanoseconds) when dev-set_next_event() is
called.
dev-next_event = expires;
is done right
On 02/16/2007 01:51 PM, Zachary Amsden wrote:
Keir Fraser wrote:
On 16/2/07 17:46, "Jeremy Fitzhardinge" <[EMAIL PROTECTED]> wrote:
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT
On 02/16/2007 12:05 AM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote:
HZ - I'm assuming dynticks will appear in the short term, and this will
become moot
Doesn't Xen send any non-blocked domain a 100hz alarm implicitly,
without anyway
On 02/16/2007 12:05 AM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote:
HZ - I'm assuming dynticks will appear in the short term, and this will
become moot
Doesn't Xen send any non-blocked domain a 100hz alarm implicitly,
without anyway
On 02/16/2007 01:51 PM, Zachary Amsden wrote:
Keir Fraser wrote:
On 16/2/07 17:46, Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Keir Fraser wrote:
This initial patchset does not include save/restore support anyway, so in
fact it would be consistent to have CONFIG_PREEMPT
On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote:
HZ - I'm assuming dynticks will appear in the short term, and this will
become moot
Doesn't Xen send any non-blocked domain a 100hz alarm implicitly,
without anyway for the guest to disable it? I guess you'll have to
break kernel/hypervisor
On 02/15/2007 06:25 PM, Jeremy Fitzhardinge wrote:
The XEN config option enables the Xen paravirt_ops interface, which is
installed when the kernel finds itself running under Xen. (By some
as-yet fully defined mechanism, implemented in a future patch.)
Xen is no longer a sub-architecture, so
On 02/15/2007 06:25 PM, Jeremy Fitzhardinge wrote:
The XEN config option enables the Xen paravirt_ops interface, which is
installed when the kernel finds itself running under Xen. (By some
as-yet fully defined mechanism, implemented in a future patch.)
Xen is no longer a sub-architecture, so
On 02/15/2007 11:04 PM, Jeremy Fitzhardinge wrote:
HZ - I'm assuming dynticks will appear in the short term, and this will
become moot
Doesn't Xen send any non-blocked domain a 100hz alarm implicitly,
without anyway for the guest to disable it? I guess you'll have to
break kernel/hypervisor
On 02/13/2007 05:36 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Why doesn't Xen allocate the shared_info page from the pseudo-physical
space? Doesn't it already have to steal pages from the
pseudo-physical space for e.g. initial page tables, console, etc? Why
not do the same
On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
Allocate a fixmap slot for use by a paravirt_ops implementation. Xen
uses this to map the hypervisor's shared info page, which doesn't have
a pseudo-physical page number, and therefore can't be mapped
ordinarily.
Why doesn't Xen allocate the
On 02/13/2007 03:29 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
I assume you plan to eventually get all this stuff working but just
want to prevent configurations that the Xen paravirt-ops isn't ready
for at the moment?
Instead can you do it this way:
config XEN
depends on PARAVIRT
On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
The XEN config option enables the Xen paravirt_ops interface, which is
installed when the kernel finds itself running under Xen. (By some
as-yet fully defined mechanism, implemented in a future patch.)
Xen is no longer a sub-architecture, so
On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
The XEN config option enables the Xen paravirt_ops interface, which is
installed when the kernel finds itself running under Xen. (By some
as-yet fully defined mechanism, implemented in a future patch.)
Xen is no longer a sub-architecture, so
On 02/13/2007 03:29 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
I assume you plan to eventually get all this stuff working but just
want to prevent configurations that the Xen paravirt-ops isn't ready
for at the moment?
Instead can you do it this way:
config XEN
depends on PARAVIRT
On 02/13/2007 02:17 PM, Jeremy Fitzhardinge wrote:
Allocate a fixmap slot for use by a paravirt_ops implementation. Xen
uses this to map the hypervisor's shared info page, which doesn't have
a pseudo-physical page number, and therefore can't be mapped
ordinarily.
Why doesn't Xen allocate the
On 02/13/2007 05:36 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Why doesn't Xen allocate the shared_info page from the pseudo-physical
space? Doesn't it already have to steal pages from the
pseudo-physical space for e.g. initial page tables, console, etc? Why
not do the same
70 matches
Mail list logo
