[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows gu
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device |
Date: |
Thu, 25 Feb 2010 15:06:05 +0000 |
User-agent: |
KMail/1.12.4 (Linux/2.6.32-trunk-amd64; KDE/4.3.4; x86_64; ; ) |
> > Idle bottom halves (i.e. qemu_bh_schedule_idle) are just bugs waiting to
> > happen, and should never be used for anything.
>
> Idle bottom halves make considerable more sense than the normal bottom
> halves.
>
> The fact that rescheduling a bottom half within a bottom half results in
> an infinite loop is absurd. It is equally absurd that bottoms halves
> alter the select timeout. The result of that is that if a bottom half
> schedules another bottom half, and that bottom half schedules the
> previous, you get a tight infinite loop. Since bottom halves are used
> often times deep within functions, the result is very subtle infinite
> loops (that we've absolutely encountered in the past).
I disagree. The "select timeout" is a completely irrelevant implementation
detail. Anything that relies on it is just plain wrong. If you require a delay
then you should be using a timer. If scheduling a BH directly then you should
expect it to be processed without delay.
If a BH reschedules itself (indirectly or indirectly) without useful work
occuring then you absolutely should expect an infinite loop. Rescheduling
itself after doing useful work should never cause an infinite loop. The only
way it can loop inifinitely is if we have infinite amount of work to do, in
which case you loose either way. Looping over work via recursive BHs is
probably not the most efficient way to do things, but I guess it may sometimes
be the simplest in practice.
Interaction between multiple BH is slightly trickier. By my reading BH are
processed in the order they are created. It may be reasonable to guarantee
that BH are processed in the order they are scheduled. However I'm reluctant
to even go that far without a good use-case. You could probably come up with
arguments for processing them in most-recently-scheduled order.
>A main loop should have only a few characteristics. It should enable
>timeouts (based on select), it should enable fd event dispatch, and it
>should allow for idle functions to be registered. There should be no
>guarantees on when idle functions are executed other than they'll
>eventually be executed.
If you don't provide any guarantees, then surely processing them immediately
must be an acceptable implementation. I don't believe there is a useful
definition of "idle".
All existing uses of qemu_bh_schedule_idle are in fact poorly implemented
periodic polling. Furthermore these should not be using periodic polling, they
can and should be event driven. They only exist because noone has bothered to
fix the old code properly. Having arbitrary 10ms latency on DMA transfers is
just plain wrong.
>The way we use "bottom halves" today should be implemented in terms of a
>relative timeout of 0 or an absolute timeout of now. The fact that we
>can't do that in our main loop is due to the very strange dependencies
>deep within various devices on io dispatch ordering. I would love to
>eliminate this but I've not been able to spend any time on this recently.
I don't see how this helps. A self-triggering event with a timeout of "now" is
still an infinite loop. Any delay is a bugs in the dispatch loop. "idle" BHs
are relying on this bug.
Paul
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Paul Brook, 2010/02/23
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Anthony Liguori, 2010/02/24
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device,
Paul Brook <=
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Avi Kivity, 2010/02/25
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Anthony Liguori, 2010/02/25
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Avi Kivity, 2010/02/25
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, malc, 2010/02/25
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Anthony Liguori, 2010/02/25
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Avi Kivity, 2010/02/26
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Anthony Liguori, 2010/02/26
- Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device, Avi Kivity, 2010/02/26