On 12/02/2016 12:12 PM, Stefan Hajnoczi wrote:
On Thu, Dec 01, 2016 at 09:35:27AM -0500, Paolo Bonzini wrote:
Maybe we could do the same for sockets? When data is available on a
socket (or when it becomes writable), write to a user memory location.
I, too, have an interest in polling; in my
On 12/01/2016 04:35 PM, Paolo Bonzini wrote:
Maybe we could do the same for sockets? When data is available on a
socket (or when it becomes writable), write to a user memory location.
I, too, have an interest in polling; in my situation most of the polling
happens in userspace.
You are tryin
Paolo Bonzini writes:
> On 30/11/2016 10:46, Peter Maydell wrote:
>>> > The problem is indeed with the scheduling. The way it currently works
>>> > is to depend on the iothread to kick a reschedule once in a while, or
>>> > a cpu to issue an instruction that does so (wfe/wfi). However if
>>> > t
On Thu, Dec 01, 2016 at 09:35:27AM -0500, Paolo Bonzini wrote:
> > > > Maybe we could do the same for sockets? When data is available on a
> > > > socket (or when it becomes writable), write to a user memory location.
> > > >
> > > > I, too, have an interest in polling; in my situation most of the
> > > Maybe we could do the same for sockets? When data is available on a
> > > socket (or when it becomes writable), write to a user memory location.
> > >
> > > I, too, have an interest in polling; in my situation most of the polling
> > > happens in userspace.
> >
> > You are trying to improve
On 12/01/2016 01:45 PM, Stefan Hajnoczi wrote:
On Wed, Nov 30, 2016 at 07:41:11PM +0200, Avi Kivity wrote:
On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote:
On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:
On 28/11/2016 16:29, Stefan Hajnoczi wrote:
Thanks for sharing the link. I'
On Wed, Nov 30, 2016 at 07:41:11PM +0200, Avi Kivity wrote:
> On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote:
> > On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:
> > > On 28/11/2016 16:29, Stefan Hajnoczi wrote:
> > > > Thanks for sharing the link. I'll let you know before embarking
On 11/29/2016 12:45 PM, Stefan Hajnoczi wrote:
On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:
On 28/11/2016 16:29, Stefan Hajnoczi wrote:
Thanks for sharing the link. I'll let you know before embarking on an
effort to make epoll support busy_loop.
At the moment I'm still eva
On Wed, Nov 30, 2016 at 06:50:09PM +0800, Fam Zheng wrote:
> On Wed, 11/30 09:38, Stefan Hajnoczi wrote:
> > On Wed, Nov 30, 2016 at 01:42:14PM +0800, Fam Zheng wrote:
> > > On Tue, 11/29 20:43, Stefan Hajnoczi wrote:
> > > > On Tue, Nov 29, 2016 at 1:24 PM, Fam Zheng wrote:
> > > > > On Tue, 11/2
On 30/11/2016 10:46, Peter Maydell wrote:
>> > The problem is indeed with the scheduling. The way it currently works
>> > is to depend on the iothread to kick a reschedule once in a while, or
>> > a cpu to issue an instruction that does so (wfe/wfi). However if
>> > there's no io and a cpu never
On Wed, 11/30 09:38, Stefan Hajnoczi wrote:
> On Wed, Nov 30, 2016 at 01:42:14PM +0800, Fam Zheng wrote:
> > On Tue, 11/29 20:43, Stefan Hajnoczi wrote:
> > > On Tue, Nov 29, 2016 at 1:24 PM, Fam Zheng wrote:
> > > > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> > > >> On 29/11/2016 11:32, Fam Zheng
On Wed, Nov 30, 2016 at 01:42:14PM +0800, Fam Zheng wrote:
> On Tue, 11/29 20:43, Stefan Hajnoczi wrote:
> > On Tue, Nov 29, 2016 at 1:24 PM, Fam Zheng wrote:
> > > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> > >> On 29/11/2016 11:32, Fam Zheng wrote:
> > >> * it still needs a system call before p
On 30 November 2016 at 09:05, Andrew Jones wrote:
> The problem is indeed with the scheduling. The way it currently works
> is to depend on the iothread to kick a reschedule once in a while, or
> a cpu to issue an instruction that does so (wfe/wfi). However if
> there's no io and a cpu never issue
On Wed, Nov 30, 2016 at 07:19:12AM +, Peter Maydell wrote:
> On 29 November 2016 at 19:38, Andrew Jones wrote:
> > Thanks for making me look, I was simply assuming we were in the while
> > loops above.
> >
> > I couldn't get the problem to reproduce with access to the monitor,
> > but by addin
On 29 November 2016 at 19:38, Andrew Jones wrote:
> Thanks for making me look, I was simply assuming we were in the while
> loops above.
>
> I couldn't get the problem to reproduce with access to the monitor,
> but by adding '-d exec' I was able to see cpu0 was on the wfe in
> smp_boot_secondary.
On Tue, 11/29 20:43, Stefan Hajnoczi wrote:
> On Tue, Nov 29, 2016 at 1:24 PM, Fam Zheng wrote:
> > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> >> On 29/11/2016 11:32, Fam Zheng wrote:
> >> * it still needs a system call before polling is entered. Ideally, QEMU
> >> could run without any system c
On Tue, Nov 29, 2016 at 1:24 PM, Fam Zheng wrote:
> On Tue, 11/29 12:17, Paolo Bonzini wrote:
>> On 29/11/2016 11:32, Fam Zheng wrote:
>> * it still needs a system call before polling is entered. Ideally, QEMU
>> could run without any system call while in polling mode.
>>
>> Another possibility i
On Tue, Nov 29, 2016 at 05:13:27PM +0100, Paolo Bonzini wrote:
>
>
> On 29/11/2016 17:01, Andrew Jones wrote:
> > OK, it may be due to scheduling then. Below is the test case (for AArch64)
> > Also, I forgot to mention before that I can only see this with TCG, not
> > KVM. If ppoll is allowed to
On Tue, Nov 29, 2016 at 11:39:44PM +0800, Fam Zheng wrote:
> On Tue, 11/29 16:24, Andrew Jones wrote:
> > On Tue, Nov 29, 2016 at 10:17:46PM +0800, Fam Zheng wrote:
> > > On Tue, 11/29 14:27, Paolo Bonzini wrote:
> > > >
> > > >
> > > > On 29/11/2016 14:24, Fam Zheng wrote:
> > > > > On Tue, 11/2
On 29/11/2016 17:01, Andrew Jones wrote:
> OK, it may be due to scheduling then. Below is the test case (for AArch64)
> Also, I forgot to mention before that I can only see this with TCG, not
> KVM. If ppoll is allowed to timeout, then the test will complete. If not,
> then, as can be seen with s
On 29/11/2016 16:24, Andrew Jones wrote:
> While we have a ppoll audience, another issue with the current polling
> is that we can block with an infinite timeout set (-1), and it can
> actually end up being infinite, i.e. vcpus will never run again. I'm
> able to exhibit this with kvm-unit-tests.
On Tue, 11/29 16:24, Andrew Jones wrote:
> On Tue, Nov 29, 2016 at 10:17:46PM +0800, Fam Zheng wrote:
> > On Tue, 11/29 14:27, Paolo Bonzini wrote:
> > >
> > >
> > > On 29/11/2016 14:24, Fam Zheng wrote:
> > > > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> > > >>
> > > >>
> > > >> On 29/11/2016 11
On Tue, Nov 29, 2016 at 10:17:46PM +0800, Fam Zheng wrote:
> On Tue, 11/29 14:27, Paolo Bonzini wrote:
> >
> >
> > On 29/11/2016 14:24, Fam Zheng wrote:
> > > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> > >>
> > >>
> > >> On 29/11/2016 11:32, Fam Zheng wrote:
> > >>>
> > >>> The kernel change wil
On Mon, Nov 28, 2016 at 4:31 AM, Eliezer Tamir
wrote:
> + Eric, Willem
>
> On 24/11/2016 17:12, Stefan Hajnoczi wrote:
>> I looked through the socket SO_BUSY_POLL and blk_mq poll support in
>> recent Linux kernels with an eye towards integrating the ongoing QEMU
>> polling work. The main missing
On Tue, 11/29 14:27, Paolo Bonzini wrote:
>
>
> On 29/11/2016 14:24, Fam Zheng wrote:
> > On Tue, 11/29 12:17, Paolo Bonzini wrote:
> >>
> >>
> >> On 29/11/2016 11:32, Fam Zheng wrote:
> >>>
> >>> The kernel change will be a new prctl operation (should it be a different
> >>> syscall to extend?)
On 29/11/2016 14:24, Fam Zheng wrote:
> On Tue, 11/29 12:17, Paolo Bonzini wrote:
>>
>>
>> On 29/11/2016 11:32, Fam Zheng wrote:
>>>
>>> The kernel change will be a new prctl operation (should it be a different
>>> syscall to extend?) to register a new type of eventfd called "idle eventfd":
>>>
>
On Tue, 11/29 12:17, Paolo Bonzini wrote:
>
>
> On 29/11/2016 11:32, Fam Zheng wrote:
> >
> > The kernel change will be a new prctl operation (should it be a different
> > syscall to extend?) to register a new type of eventfd called "idle eventfd":
> >
> > prctl(PR_ADD_IDLE_EVENTFD, int eve
On 11/29/2016 12:00 PM, Stefan Hajnoczi wrote:
> On Tue, Nov 29, 2016 at 09:19:22AM +0100, Christian Borntraeger wrote:
>> On 11/24/2016 04:12 PM, Stefan Hajnoczi wrote:
>>> I looked through the socket SO_BUSY_POLL and blk_mq poll support in
>>> recent Linux kernels with an eye towards integrating
On 29/11/2016 11:32, Fam Zheng wrote:
>
> The kernel change will be a new prctl operation (should it be a different
> syscall to extend?) to register a new type of eventfd called "idle eventfd":
>
> prctl(PR_ADD_IDLE_EVENTFD, int eventfd);
> prctl(PR_DEL_IDLE_EVENTFD, int eventfd);
>
>
On Tue, Nov 29, 2016 at 09:19:22AM +0100, Christian Borntraeger wrote:
> On 11/24/2016 04:12 PM, Stefan Hajnoczi wrote:
> > I looked through the socket SO_BUSY_POLL and blk_mq poll support in
> > recent Linux kernels with an eye towards integrating the ongoing QEMU
> > polling work. The main missi
On Mon, Nov 28, 2016 at 04:41:13PM +0100, Paolo Bonzini wrote:
> On 28/11/2016 16:29, Stefan Hajnoczi wrote:
> > Thanks for sharing the link. I'll let you know before embarking on an
> > effort to make epoll support busy_loop.
> >
> > At the moment I'm still evaluating whether the good results we
On Thu, 11/24 15:12, Stefan Hajnoczi wrote:
> QEMU and KVM-specific polling
> -
> There are a few QEMU/KVM-specific items that require polling support:
>
> QEMU's event loop aio_notify() mechanism wakes up the event loop from a
> blocking poll(2) or epoll call. It is u
On 11/24/2016 04:12 PM, Stefan Hajnoczi wrote:
> I looked through the socket SO_BUSY_POLL and blk_mq poll support in
> recent Linux kernels with an eye towards integrating the ongoing QEMU
> polling work. The main missing feature is eventfd polling support which
> I describe below.
>
> Background
On 28/11/2016 16:29, Stefan Hajnoczi wrote:
> Thanks for sharing the link. I'll let you know before embarking on an
> effort to make epoll support busy_loop.
>
> At the moment I'm still evaluating whether the good results we've gotten
> from polling in QEMU userspace are preserved when polling
On Mon, Nov 28, 2016 at 11:31:43AM +0200, Eliezer Tamir wrote:
> + Eric, Willem
>
> On 24/11/2016 17:12, Stefan Hajnoczi wrote:
> > I looked through the socket SO_BUSY_POLL and blk_mq poll support in
> > recent Linux kernels with an eye towards integrating the ongoing QEMU
> > polling work. The m
+ Eric, Willem
On 24/11/2016 17:12, Stefan Hajnoczi wrote:
> I looked through the socket SO_BUSY_POLL and blk_mq poll support in
> recent Linux kernels with an eye towards integrating the ongoing QEMU
> polling work. The main missing feature is eventfd polling support which
> I describe below.
..
I looked through the socket SO_BUSY_POLL and blk_mq poll support in
recent Linux kernels with an eye towards integrating the ongoing QEMU
polling work. The main missing feature is eventfd polling support which
I describe below.
Background
--
We're experimenting with polling in QEMU so I w
37 matches
Mail list logo
