On Thu, 07 May 2020 17:03:46 +0200
Christian Schoenebeck wrote:
> On Donnerstag, 7. Mai 2020 16:33:28 CEST Greg Kurz wrote:
> > > I also haven't reviewed QEMU's lock implementations in very detail, but
> > > IIRC CoMutexes are completely handled in user space, while QemuMutex uses
> > > regular
On Donnerstag, 7. Mai 2020 16:33:28 CEST Greg Kurz wrote:
> > I also haven't reviewed QEMU's lock implementations in very detail, but
> > IIRC CoMutexes are completely handled in user space, while QemuMutex uses
> > regular OS mutexes and hence might cost context switches.
>
> ... since the
On Thu, 07 May 2020 13:37:30 +0200
Christian Schoenebeck wrote:
> On Mittwoch, 6. Mai 2020 19:49:10 CEST Greg Kurz wrote:
> > > Ok, but why not both? Moving locks to worker thread and QemuMutex ->
> > > CoMutex?
> > Using CoMutex would be mandatory if we leave the locking where it sits
> >
On Thu, 07 May 2020 13:46:50 +0200
Christian Schoenebeck wrote:
> On Mittwoch, 6. Mai 2020 19:54:15 CEST Greg Kurz wrote:
> > On Wed, 06 May 2020 15:36:16 +0200
> >
> > Christian Schoenebeck wrote:
> > > On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote:
> > > > > diff --git
On Mittwoch, 6. Mai 2020 19:54:15 CEST Greg Kurz wrote:
> On Wed, 06 May 2020 15:36:16 +0200
>
> Christian Schoenebeck wrote:
> > On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote:
> > > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > > index 9e046f7acb51..ac84ae804496 100644
>
On Mittwoch, 6. Mai 2020 19:49:10 CEST Greg Kurz wrote:
> > Ok, but why not both? Moving locks to worker thread and QemuMutex ->
> > CoMutex?
> Using CoMutex would be mandatory if we leave the locking where it sits
> today, so that the main thread can switch to other coroutines instead
> of
On Wed, 06 May 2020 15:36:16 +0200
Christian Schoenebeck wrote:
> On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote:
> > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > > index 9e046f7acb51..ac84ae804496 100644
> > > --- a/hw/9pfs/9p.c
> > > +++ b/hw/9pfs/9p.c
> > > @@ -2170,7
On Wed, 06 May 2020 15:05:23 +0200
Christian Schoenebeck wrote:
> On Donnerstag, 30. April 2020 17:53:34 CEST Greg Kurz wrote:
> > Locking was introduced to address the deprecation of readdir_r(3)
> > in glibc 2.24. It turns out that the frontend code is the worst
> > place to handle a critical
On Mittwoch, 6. Mai 2020 15:05:23 CEST Christian Schoenebeck wrote:
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index 9e046f7acb51..ac84ae804496 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -2170,7 +2170,7 @@ static int coroutine_fn
> > v9fs_do_readdir_with_stat(V9fsPDU *pdu,
On Donnerstag, 30. April 2020 17:53:34 CEST Greg Kurz wrote:
> Locking was introduced to address the deprecation of readdir_r(3)
> in glibc 2.24. It turns out that the frontend code is the worst
> place to handle a critical section with a pthread mutex: the code
> runs in a coroutine on behalf of
Locking was introduced to address the deprecation of readdir_r(3)
in glibc 2.24. It turns out that the frontend code is the worst
place to handle a critical section with a pthread mutex: the code
runs in a coroutine on behalf of the QEMU mainloop and then yields
control, waiting for the fsdev
11 matches
Mail list logo