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 o
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 c
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
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
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
> 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 yo
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 p
> ??? 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 t
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 wi
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 har
> 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
> 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 somethi
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 ignora
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 t
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 need
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
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 ud
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 de
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 injur
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 b
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 drivers/in
31 matches
Mail list logo
