On Tue, Aug 16, 2016 at 12:16:26 +0100, Alex Bennée wrote:
> Emilio G. Cota writes:
> > However, I'm finding issues that might not have to do with the
> > patch itself.
I had some time today to dig deeper -- turns out the issues *have*
to do with my patch, see below. (And sorry for hijacking this
Emilio G. Cota writes:
> On Mon, Aug 15, 2016 at 11:46:32 +0100, Alex Bennée wrote:
>> As far as I'm aware the following work is still ongoing:
>>
>> Emilo: cmpxchg atomics
>> Alvise: LL/SC modelling
>
> I've been tinkering with an experimental patch to do proper LL/SC. The idea
> is to rely on
On Mon, Aug 15, 2016 at 11:46:32 +0100, Alex Bennée wrote:
> As far as I'm aware the following work is still ongoing:
>
> Emilo: cmpxchg atomics
> Alvise: LL/SC modelling
I've been tinkering with an experimental patch to do proper LL/SC. The idea
is to rely on hardware transactional memory, so th
Peter Maydell writes:
> On 15 August 2016 at 11:46, Alex Bennée wrote:
>> I only ran up to -smp 8 as that is as
>> much as the -m virt model will actually accept.
>
> FWIW, -machine gic-version=3 should allow you more than 8 cores.
Good to know. Thanks.
>> I have noticed some instability in t
On 15 August 2016 at 11:46, Alex Bennée wrote:
> I only ran up to -smp 8 as that is as
> much as the -m virt model will actually accept.
FWIW, -machine gic-version=3 should allow you more than 8 cores.
> I have noticed some instability in the test though for high -smp values
> which caused the t
Hi,
Numbers!
First things first, I ran some more benchmarks on the base patches +
cmpxchg branch over the weekend when I had access to some bigger boxen
which weren't being used. I also added some KVM runs for comparison:
━
