diff mbox

TCG baremetal tests repo

Message ID 558C25D9.80300@greensocs.com
State New
Headers show

Commit Message

fred.konrad@greensocs.com June 25, 2015, 4:01 p.m. UTC 
On 22/06/2015 12:54, Alexander Spyridakis wrote:
> Hello all,
>
> You can find the latest tcg atomic test payload in the following repo:
> > git clone https://git.virtualopensystems.com/dev/tcg_baremetal_tests.git
>
> You also need an arm baremetal cross-compiler like arm-none-gnueabi- 
> (arm) and the usual aarch64-linux-gnu- (arm64). Due to a PSCI bug in 
> the current multithreading tcg repo, the atomic test was modified to 
> work also on the vexpress machine model.
>
> To run it:
> > make vexpress (or virt/virt64 for other targets)
> > ../mttcg/arm-softmmu/qemu-system-arm -nographic -M vexpress-a15 
> -kernel build-vexpress/image-vexpress.axf -smp 4
>
> On my machine it takes around 30 seconds for one run of the test and 
> the results vary from as low as 5 to 30 errors per vCPU per 10 million 
> iterations (no errors with KVM). It is also very interesting to note, 
> that the current test finishes faster on upstream qemu than 
> multithreaded qemu.
>
> Best regards.

Hi,

I just tested this with vexpress, seems ATOMIC is not defined by default 
it uses:

void non_atomic_lock(int *lock_var)
{
     while (*lock_var != 0);
     *lock_var = 1;
}

void non_atomic_unlock(int *lock_var)
{
     *lock_var = 0;
}

instead of:

void atomic_lock(int *lock_var)
{
     while (__sync_lock_test_and_set(lock_var, 1));
}

void atomic_unlock(int *lock_var)
{
     __sync_lock_release(lock_var);
}

It doesn't cause any errors upstream but a lot on mttcg and mttcg is 
faster in this
case.

I don't have any error when I use ATOMIC like this:


but it's slower than upstream which I think is normal. We can have two CPUs
fighting for the lock in mttcg but not in upstream as VCPUs doesn't run 
at the same
time.

Fred

Comments

Alexander Spyridakis June 26, 2015, 12:26 a.m. UTC | #1 
On 25 June 2015 at 18:01, Frederic Konrad <fred.konrad@greensocs.com> wrote:
> I just tested this with vexpress, seems ATOMIC is not defined by default it
> uses:

Wow nice catch! Somehow between revision the define was no longer
propagated and ATOMIC was not defined at all.

Tested with 8 cores and no more errors. As you said performance is
still slower but probably due to the continuous contesting of the
lock.

Thanks.
diff mbox

Patch

diff --git a/helpers.h b/helpers.h
index b5810ad..427659f 100644
--- a/helpers.h
+++ b/helpers.h
@@ -36,13 +36,8 @@ 
  #define SYS_CFGCTR_WRITE   0x40000000
  #define SYS_CFG_SHUTDOWN   0x00800000

-#ifdef ATOMIC
  #define LOCK   atomic_lock
  #define UNLOCK atomic_unlock
-#else
-#define LOCK   non_atomic_lock
-#define UNLOCK non_atomic_unlock
-#endif

  int online_cpus;
  int global_lock;