On 2020/12/15 0:33, Stefan Hajnoczi wrote:
> On Tue, Dec 08, 2020 at 08:47:42AM -0500, Glauber Costa wrote:
>> The work we did at the time was in fixing those things in the kernel
>> as much as we could.
>> But the API is just like that...
>
The best way for us is to replace io_submit with
On Tue, Dec 08, 2020 at 08:47:42AM -0500, Glauber Costa wrote:
> The work we did at the time was in fixing those things in the kernel
> as much as we could.
> But the API is just like that...
Thanks!
Stefan
signature.asc
Description: PGP signature
On Tue, Dec 8, 2020 at 8:11 AM Stefan Hajnoczi wrote:
>
> On Thu, Oct 22, 2020 at 05:29:16PM +0100, Fam Zheng wrote:
> > On Tue, 2020-10-20 at 09:34 +0800, Zhenyu Ye wrote:
> > > On 2020/10/19 21:25, Paolo Bonzini wrote:
> > > > On 19/10/20 14:40, Zhenyu Ye wrote:
> > > > > The kernel backtrace
On Thu, Oct 22, 2020 at 05:29:16PM +0100, Fam Zheng wrote:
> On Tue, 2020-10-20 at 09:34 +0800, Zhenyu Ye wrote:
> > On 2020/10/19 21:25, Paolo Bonzini wrote:
> > > On 19/10/20 14:40, Zhenyu Ye wrote:
> > > > The kernel backtrace for io_submit in GUEST is:
> > > >
> > > > guest#
On Tue, 2020-10-20 at 09:34 +0800, Zhenyu Ye wrote:
> On 2020/10/19 21:25, Paolo Bonzini wrote:
> > On 19/10/20 14:40, Zhenyu Ye wrote:
> > > The kernel backtrace for io_submit in GUEST is:
> > >
> > > guest# ./offcputime -K -p `pgrep -nx fio`
> > > b'finish_task_switch'
> > >
On 2020/10/19 21:25, Paolo Bonzini wrote:
> On 19/10/20 14:40, Zhenyu Ye wrote:
>> The kernel backtrace for io_submit in GUEST is:
>>
>> guest# ./offcputime -K -p `pgrep -nx fio`
>> b'finish_task_switch'
>> b'__schedule'
>> b'schedule'
>> b'io_schedule'
>>
On 19/10/20 14:40, Zhenyu Ye wrote:
> The kernel backtrace for io_submit in GUEST is:
>
> guest# ./offcputime -K -p `pgrep -nx fio`
> b'finish_task_switch'
> b'__schedule'
> b'schedule'
> b'io_schedule'
> b'blk_mq_get_tag'
>
Hi Stefan,
On 2020/10/13 18:00, Stefan Hajnoczi wrote:
>
> Sorry, I lost track of this on-going email thread.
>
> Thanks for the backtrace. It shows the io_submit call is done while the
> AioContext lock is held. The monitor thread is waiting for the
> IOThread's AioContext lock. vcpus threads
On Mon, Sep 21, 2020 at 11:14:35AM +, Fam Zheng wrote:
> On 2020-09-19 10:22, Zhenyu Ye wrote:
> > On 2020/9/18 22:06, Fam Zheng wrote:
> > >
> > > I can see how blocking in a slow io_submit can cause trouble for main
> > > thread. I think one way to fix it (until it's made truly async in new
On 2020-09-19 10:22, Zhenyu Ye wrote:
> On 2020/9/18 22:06, Fam Zheng wrote:
> >
> > I can see how blocking in a slow io_submit can cause trouble for main
> > thread. I think one way to fix it (until it's made truly async in new
> > kernels) is moving the io_submit call to thread pool, and
On 2020/9/18 22:06, Fam Zheng wrote:
>
> I can see how blocking in a slow io_submit can cause trouble for main
> thread. I think one way to fix it (until it's made truly async in new
> kernels) is moving the io_submit call to thread pool, and wrapped in a
> coroutine, perhaps.
>
I'm not sure if
On 2020-09-18 19:23, Zhenyu Ye wrote:
> Thread 5 (LWP 4802):
> #0 0x83086b54 in syscall () at /lib64/libc.so.6
> #1 0x834598b8 in io_submit () at /lib64/libaio.so.1
> #2 0xe851e89c in ioq_submit (s=0xfffd3c001bb0) at
> ../block/linux-aio.c:299
>
Hi Stefan, Fam,
On 2020/9/18 0:01, Fam Zheng wrote:
> On 2020-09-17 16:44, Stefan Hajnoczi wrote:
>> On Thu, Sep 17, 2020 at 03:36:57PM +0800, Zhenyu Ye wrote:
>>> When the hang occurs, the QEMU is blocked at:
>>>
>>> #0 0x95762b64 in ?? () from target:/usr/lib64/libpthread.so.0
>>>
On 2020-09-17 16:44, Stefan Hajnoczi wrote:
> On Thu, Sep 17, 2020 at 03:36:57PM +0800, Zhenyu Ye wrote:
> > When the hang occurs, the QEMU is blocked at:
> >
> > #0 0x95762b64 in ?? () from target:/usr/lib64/libpthread.so.0
> > #1 0x9575bd88 in pthread_mutex_lock ()
On Thu, Sep 17, 2020 at 03:36:57PM +0800, Zhenyu Ye wrote:
> When the hang occurs, the QEMU is blocked at:
>
> #0 0x95762b64 in ?? () from target:/usr/lib64/libpthread.so.0
> #1 0x9575bd88 in pthread_mutex_lock () from
> target:/usr/lib64/libpthread.so.0
> #2
On 2020-09-17 15:36, Zhenyu Ye wrote:
> Hi Stefan,
>
> On 2020/9/14 21:27, Stefan Hajnoczi wrote:
> >>
> >> Theoretically, everything running in an iothread is asynchronous. However,
> >> some 'asynchronous' actions are not non-blocking entirely, such as
> >> io_submit(). This will block while
Hi Daniel,
On 2020/9/14 22:42, Daniel P. Berrangé wrote:
> On Tue, Aug 11, 2020 at 09:54:08PM +0800, Zhenyu Ye wrote:
>> Hi Kevin,
>>
>> On 2020/8/10 23:38, Kevin Wolf wrote:
>>> Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
Before doing qmp actions, we need to lock the
Hi Stefan,
On 2020/9/14 21:27, Stefan Hajnoczi wrote:
>>
>> Theoretically, everything running in an iothread is asynchronous. However,
>> some 'asynchronous' actions are not non-blocking entirely, such as
>> io_submit(). This will block while the iodepth is too big and I/O pressure
>> is too
On Tue, Aug 11, 2020 at 09:54:08PM +0800, Zhenyu Ye wrote:
> Hi Kevin,
>
> On 2020/8/10 23:38, Kevin Wolf wrote:
> > Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
> >> Before doing qmp actions, we need to lock the qemu_global_mutex,
> >> so the qmp actions should not take too long time.
> >>
On Tue, Aug 11, 2020 at 09:54:08PM +0800, Zhenyu Ye wrote:
> Hi Kevin,
>
> On 2020/8/10 23:38, Kevin Wolf wrote:
> > Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
> >> Before doing qmp actions, we need to lock the qemu_global_mutex,
> >> so the qmp actions should not take too long time.
> >>
On Tue, Aug 11, 2020 at 09:54:08PM +0800, Zhenyu Ye wrote:
> Hi Kevin,
>
> On 2020/8/10 23:38, Kevin Wolf wrote:
> > Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
> >> Before doing qmp actions, we need to lock the qemu_global_mutex,
> >> so the qmp actions should not take too long time.
> >>
Hi Stefan,
On 2020/8/12 21:51, Stefan Hajnoczi wrote:
> On Mon, Aug 10, 2020 at 10:52:44PM +0800, Zhenyu Ye wrote:
>> Before doing qmp actions, we need to lock the qemu_global_mutex,
>> so the qmp actions should not take too long time.
>>
>> Unfortunately, some qmp actions need to acquire aio
On Mon, Aug 10, 2020 at 10:52:44PM +0800, Zhenyu Ye wrote:
> Before doing qmp actions, we need to lock the qemu_global_mutex,
> so the qmp actions should not take too long time.
>
> Unfortunately, some qmp actions need to acquire aio context and
> this may take a long time. The vm will soft
Hi Kevin,
On 2020/8/10 23:38, Kevin Wolf wrote:
> Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
>> Before doing qmp actions, we need to lock the qemu_global_mutex,
>> so the qmp actions should not take too long time.
>>
>> Unfortunately, some qmp actions need to acquire aio context and
>>
Am 10.08.2020 um 16:52 hat Zhenyu Ye geschrieben:
> Before doing qmp actions, we need to lock the qemu_global_mutex,
> so the qmp actions should not take too long time.
>
> Unfortunately, some qmp actions need to acquire aio context and
> this may take a long time. The vm will soft lockup if
Before doing qmp actions, we need to lock the qemu_global_mutex,
so the qmp actions should not take too long time.
Unfortunately, some qmp actions need to acquire aio context and
this may take a long time. The vm will soft lockup if this time
is too long.
So add a timeout mechanism while doing
26 matches
Mail list logo
