qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: MTTCG Devel <mttcg@listserver.greensocs.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Cc: "Mark Burton" <mark.burton@greensocs.com>,
	"KONRAD Frédéric" <fred.konrad@greensocs.com>,
	"Alvise Rigo" <a.rigo@virtualopensystems.com>,
	"Sergey Fedorov" <serge.fdrv@gmail.com>,
	"Emilio G. Cota" <cota@braap.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Pranith Kumar" <bobby.prani@gmail.com>
Subject: [Qemu-devel] Any topics for today's MTTCG sync-up call?
Date: Mon, 04 Jul 2016 10:46:39 +0100	[thread overview]
Message-ID: <87r3b9n3b4.fsf@linaro.org> (raw)


Hi,

It's been a while since we've actually held the call. Here are some
things that might be worth discussing:

Soft Freeze
===========

This cycles soft-freeze is upon us. QHT has already been merged this
cycle which is a win. I've taken some of the lock contention patches
from my base enabling patches which improve the situation for linux-user
mode which I hope to get accepted this cycle (as they have been on the
list before and just need minor tweaks).

Are there any other patches that meet the soft-freeze criteria worth
trying to merge this cycle?

Quiescent Work
==============

Sergey has posted a series of patches that attempt to draw together all
the requirements of the various safe work patches into a common feature
that can be meet all the various use cases we have. It comes with a
thread safe tb_flush implementation although obviously there are other
uses in LL/SC and system emulation tasks. Is everyone happy with the
features it provides?

Atomics
=======

Emilio has posted his set of patches for implementing atomics in a
thread safe manner. So far I've only had a chance to glance over it but
it certainly has some interesting numbers. I suspect the next step will
be some serious benmarking between this and Alvise's upcoming re-base to
solve the race between an initial LL and the flushing of the TLB
entries.

As I understand it the LL/SC work will require some quiescent work to
complete before things can continue in a race free manner. The question
is if this cost is too high compared to Emilio's solution which suffers
from ABA but for practical purposes should be fine.

My intention is to build trees of both solutions on top of the base
patches and compare their performances on both real-world and artificial
work-loads.

Memory Ordering
===============

Pranith has posted a series of patches to the list the implement basic
memory ordering TCGOps. The current discussions centre mainly around the
best way to represent Acq/Rel semantics in an efficient manner.

Base-enabling patches
=====================

Since the posting of v3 I've had some feedback so I'll be update v4
while the other trees get reviewed before trying to build another
complete series (probably ARM based) and doing some benchmarking of the
system performance.

Any other topics that need discussion?

--
Alex Bennée

             reply	other threads:[~2016-07-04  9:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04  9:46 Alex Bennée [this message]
2016-07-04 13:08 ` [Qemu-devel] Any topics for today's MTTCG sync-up call? Alex Bennée
  -- strict thread matches above, loose matches on Subject: below --
2016-06-20 11:57 Alex Bennée
2016-06-20 13:01 ` alvise rigo
2016-06-20 14:12   ` Alex Bennée
2016-06-20 14:18     ` alvise rigo
2016-05-23 10:57 Alex Bennée
2016-05-23 12:03 ` alvise rigo
2016-05-23 12:47   ` Alex Bennée
2016-05-23 12:57     ` Claudio Fontana
2016-05-23 13:16       ` Alex Bennée
2016-05-23 15:22       ` Emilio G. Cota
2016-05-23 15:28 ` Emilio G. Cota

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r3b9n3b4.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=a.rigo@virtualopensystems.com \
    --cc=bobby.prani@gmail.com \
    --cc=cota@braap.org \
    --cc=fred.konrad@greensocs.com \
    --cc=mark.burton@greensocs.com \
    --cc=mttcg@listserver.greensocs.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=serge.fdrv@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).