On Thu, 2007-02-15 at 15:42 -0800, Zachary Amsden wrote:
> So Rusty, Chris, Jeremy, any objections to killing udelay() and friends
> in paravirt-ops? It would simplify things a bit.
I agree.
Thanks!
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Zachary Amsden wrote:
> So Rusty, Chris, Jeremy, any objections to killing udelay() and
> friends in paravirt-ops? It would simplify things a bit. The only
> thing we lose is a slightly faster boot time in the 100% emulated
> device case. I'm ok with losing that. Even the PIT fast paths don't
Hi!
> >You know it is ugly. Alan demonstrated it even hurts performance, but
> >being ugly is the main problem.
> >
>
> No argument with that. Well, we're ok with dropping it. Actually,
> reverting the entire set of udelay changes now seems wise. The same
>bug
Good, thanks.
Pavel Machek wrote:
You know it is ugly. Alan demonstrated it even hurts performance, but
being ugly is the main problem.
No argument with that. Well, we're ok with dropping it. Actually,
reverting the entire set of udelay changes now seems wise. The same bug
that happened with i8042
On 2/14/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote:
> Failure to use real-time delay here causes the keyboard to become demonically
> possessed in the event of a kernel crash, with wildly blinking lights and
> unpredictable behavior.
Hi!
> >>We'd have to audit and figure out what udelays are for hardware and
> >>which are not, but the evidence is that the vast majority of them are
> >>for hardware and not needed for virtualization.
> >>
> >
> >Which is irrelevant since the hardware drivers won't be used in a
>
Hi!
We'd have to audit and figure out what udelays are for hardware and
which are not, but the evidence is that the vast majority of them are
for hardware and not needed for virtualization.
Which is irrelevant since the hardware drivers won't be used in a
virtualised environment with
On 2/14/07, Rusty Russell [EMAIL PROTECTED] wrote:
On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has
Pavel Machek wrote:
You know it is ugly. Alan demonstrated it even hurts performance, but
being ugly is the main problem.
No argument with that. Well, we're ok with dropping it. Actually,
reverting the entire set of udelay changes now seems wise. The same bug
that happened with i8042
Hi!
You know it is ugly. Alan demonstrated it even hurts performance, but
being ugly is the main problem.
No argument with that. Well, we're ok with dropping it. Actually,
reverting the entire set of udelay changes now seems wise. The same
bug
Good, thanks.
Zachary Amsden wrote:
So Rusty, Chris, Jeremy, any objections to killing udelay() and
friends in paravirt-ops? It would simplify things a bit. The only
thing we lose is a slightly faster boot time in the 100% emulated
device case. I'm ok with losing that. Even the PIT fast paths don't
use
On Thu, 2007-02-15 at 15:42 -0800, Zachary Amsden wrote:
So Rusty, Chris, Jeremy, any objections to killing udelay() and friends
in paravirt-ops? It would simplify things a bit.
I agree.
Thanks!
Rusty.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
On Wed, 14 Feb 2007 13:53:08 -0800
Zachary Amsden <[EMAIL PROTECTED]> wrote:
> > IDE on several platforms has performance critical paths that use
> > ndelay(400) or failing that udelay(1)
>
> Ok, I buy that. A 486DX / 33 Mhz processor takes 10 cycles to issue a
> CALL / RET pair. This is
> users I'd rather try to convince the IDE maintainer to use a
> "real_hardware_mdelay()" or something here.
The IDE/ATA layer has a single function which decides what non PCI
probing to do so could learn to spot virtualisation easily enough. In the
case of libata ISA is now obscure enough that
On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote:
> Failure to use real-time delay here causes the keyboard to become demonically
> possessed in the event of a kernel crash, with wildly blinking lights and
> unpredictable behavior. This has resulted in several injuries.
The problem is the
Alan wrote:
??? I fail to see the code bloat and also the fast paths. Which fast
paths use udelay?
IDE on several platforms has performance critical paths that use
ndelay(400) or failing that udelay(1)
Ok, I buy that. A 486DX / 33 Mhz processor takes 10 cycles to issue a
CALL / RET
> ??? I fail to see the code bloat and also the fast paths. Which fast
> paths use udelay?
IDE on several platforms has performance critical paths that use
ndelay(400) or failing that udelay(1)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
Alan wrote:
We'd have to audit and figure out what udelays are for hardware and
which are not, but the evidence is that the vast majority of them are
for hardware and not needed for virtualization.
Which is irrelevant since the hardware drivers won't be used in a
virtualised environment
Pavel Machek wrote:
On Thu 2007-02-08 07:36:12, Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized
> We'd have to audit and figure out what udelays are for hardware and
> which are not, but the evidence is that the vast majority of them are
> for hardware and not needed for virtualization.
Which is irrelevant since the hardware drivers won't be used in a
virtualised environment with any kind
> No, not that. But the virtual keyboard I/O gets processed and converted
> to physical keyboard I/O when a keyboard is attached to a VM. The
> result is that the virtual keyboard spinning out of control causes the
> physical keyboard to receive the same commands, far too rapidly.
>
> So the
On Thu 2007-02-08 07:36:12, Rusty Russell wrote:
> On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
> > Ugh, it sounds like paravirt is more b0rken then I thought. It should
> > always to the proper delay, then replace those udelays that are not
> > needed on virtualized hardware with
On Thu 2007-02-08 07:36:12, Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized hardware with something
No, not that. But the virtual keyboard I/O gets processed and converted
to physical keyboard I/O when a keyboard is attached to a VM. The
result is that the virtual keyboard spinning out of control causes the
physical keyboard to receive the same commands, far too rapidly.
So the
We'd have to audit and figure out what udelays are for hardware and
which are not, but the evidence is that the vast majority of them are
for hardware and not needed for virtualization.
Which is irrelevant since the hardware drivers won't be used in a
virtualised environment with any kind of
Pavel Machek wrote:
On Thu 2007-02-08 07:36:12, Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized
Alan wrote:
We'd have to audit and figure out what udelays are for hardware and
which are not, but the evidence is that the vast majority of them are
for hardware and not needed for virtualization.
Which is irrelevant since the hardware drivers won't be used in a
virtualised environment
??? I fail to see the code bloat and also the fast paths. Which fast
paths use udelay?
IDE on several platforms has performance critical paths that use
ndelay(400) or failing that udelay(1)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Alan wrote:
??? I fail to see the code bloat and also the fast paths. Which fast
paths use udelay?
IDE on several platforms has performance critical paths that use
ndelay(400) or failing that udelay(1)
Ok, I buy that. A 486DX / 33 Mhz processor takes 10 cycles to issue a
CALL / RET
On Mon, 2007-02-05 at 19:53 -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several injuries.
The problem is the
users I'd rather try to convince the IDE maintainer to use a
real_hardware_mdelay() or something here.
The IDE/ATA layer has a single function which decides what non PCI
probing to do so could learn to spot virtualisation easily enough. In the
case of libata ISA is now obscure enough that you
On Wed, 14 Feb 2007 13:53:08 -0800
Zachary Amsden [EMAIL PROTECTED] wrote:
IDE on several platforms has performance critical paths that use
ndelay(400) or failing that udelay(1)
Ok, I buy that. A 486DX / 33 Mhz processor takes 10 cycles to issue a
CALL / RET pair. This is about 300ns.
On 2/8/07, Zachary Amsden <[EMAIL PROTECTED]> wrote:
Dmitry Torokhov wrote:
>
> However I am not really fond of idea of adding constructs like this
> all over the code:
>
> #define USE_REAL_TIME_DELAY_I_REALLY_MEAN_IT_THIS_TIME_I_SWEAR
>
> as the time passes... Drivers should be blissfully
Dmitry Torokhov wrote:
However I am not really fond of idea of adding constructs like this
all over the code:
#define USE_REAL_TIME_DELAY_I_REALLY_MEAN_IT_THIS_TIME_I_SWEAR
as the time passes... Drivers should be blissfully ignorant of being
run on virtual hardware.
I agree in general, but
On 2/7/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
> Ugh, it sounds like paravirt is more b0rken then I thought. It should
> always to the proper delay, then replace those udelays that are not
> needed on virtualized hardware with something
On 8 Feb 2007 14:33:21 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
On Thu, Feb 08, 2007 at 01:08:14AM -0800, Zachary Amsden wrote:
> Andi Kleen wrote:
> >On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
> >
> >>Dmitry Torokhov wrote:
> >>
> >>>I am confused - does i8042 talk to a
On Thu, Feb 08, 2007 at 01:08:14AM -0800, Zachary Amsden wrote:
> Andi Kleen wrote:
> >On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
> >
> >>Dmitry Torokhov wrote:
> >>
> >>>I am confused - does i8042 talk to a virtual or real hardware here? In
> >>>any case I think you
Andi Kleen wrote:
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix kernel/panic.c to have proper
(m)delay, not mess with i8042.
I think I
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
> Dmitry Torokhov wrote:
> >
> >I am confused - does i8042 talk to a virtual or real hardware here? In
> >any case I think you need to fix kernel/panic.c to have proper
> >(m)delay, not mess with i8042.
>
> I think I need to fix both
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix kernel/panic.c to have proper
(m)delay, not mess with i8042.
I think I need to fix both of them
Andi Kleen wrote:
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix kernel/panic.c to have proper
(m)delay, not mess with i8042.
I think I
On Thu, Feb 08, 2007 at 01:08:14AM -0800, Zachary Amsden wrote:
Andi Kleen wrote:
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix
On 8 Feb 2007 14:33:21 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
On Thu, Feb 08, 2007 at 01:08:14AM -0800, Zachary Amsden wrote:
Andi Kleen wrote:
On Wed, Feb 07, 2007 at 02:31:57PM -0800, Zachary Amsden wrote:
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real
On 2/7/07, Rusty Russell [EMAIL PROTECTED] wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized hardware with something
Dmitry Torokhov wrote:
However I am not really fond of idea of adding constructs like this
all over the code:
#define USE_REAL_TIME_DELAY_I_REALLY_MEAN_IT_THIS_TIME_I_SWEAR
as the time passes... Drivers should be blissfully ignorant of being
run on virtual hardware.
I agree in general, but
On 2/8/07, Zachary Amsden [EMAIL PROTECTED] wrote:
Dmitry Torokhov wrote:
However I am not really fond of idea of adding constructs like this
all over the code:
#define USE_REAL_TIME_DELAY_I_REALLY_MEAN_IT_THIS_TIME_I_SWEAR
as the time passes... Drivers should be blissfully ignorant of
Dmitry Torokhov wrote:
I am confused - does i8042 talk to a virtual or real hardware here? In
any case I think you need to fix kernel/panic.c to have proper
(m)delay, not mess with i8042.
I think I need to fix both of them actually. This is virtual hardware,
but when you grab focus on a VM,
Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized hardware with something else.
Just magically defining
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
> Ugh, it sounds like paravirt is more b0rken then I thought. It should
> always to the proper delay, then replace those udelays that are not
> needed on virtualized hardware with something else.
>
> Just magically defining udelay into nop is
On 2/6/07, Zachary Amsden <[EMAIL PROTECTED]> wrote:
Andi Kleen wrote:
> On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
>
>> Failure to use real-time delay here causes the keyboard to become demonically
>> possessed in the event of a kernel crash, with wildly blinking lights and
Hi!
> >
> >>Failure to use real-time delay here causes the
> >>keyboard to become demonically
> >>possessed in the event of a kernel crash, with wildly
> >>blinking lights and
> >>unpredictable behavior. This has resulted in several
> >>injuries.
> >
> >There must be a reason why it wasn't
Hi!
Failure to use real-time delay here causes the
keyboard to become demonically
possessed in the event of a kernel crash, with wildly
blinking lights and
unpredictable behavior. This has resulted in several
injuries.
There must be a reason why it wasn't default before.
Has
On 2/6/07, Zachary Amsden [EMAIL PROTECTED] wrote:
Andi Kleen wrote:
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized hardware with something else.
Just magically defining udelay into nop is
Rusty Russell wrote:
On Wed, 2007-02-07 at 12:35 +, Pavel Machek wrote:
Ugh, it sounds like paravirt is more b0rken then I thought. It should
always to the proper delay, then replace those udelays that are not
needed on virtualized hardware with something else.
Just magically defining
Andi Kleen wrote:
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
> Failure to use real-time delay here causes the keyboard to become demonically
> possessed in the event of a kernel crash, with wildly blinking lights and
> unpredictable behavior. This has resulted in several injuries.
There must
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several injuries.
There must be
Andi Kleen wrote:
On Mon, Feb 05, 2007 at 07:53:30PM -0800, Zachary Amsden wrote:
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several injuries.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 10fac6d484e2
Failure to use real-time delay here causes the keyboard to become demonically
possessed in the event of a kernel crash, with wildly blinking lights and
unpredictable behavior. This has resulted in several injuries.
Signed-off-by: Zachary Amsden [EMAIL PROTECTED]
diff -r 10fac6d484e2
61 matches
Mail list logo
