Hello,

This series introduce multicore cache modelling in contrib/plugins/cache.c

Multi-core cache modelling is handled such that for full-system
emulation, a private L1 cache is maintained to each core available to
the system. For multi-threaded userspace emulation, a static number of
cores is maintained for the overall system, and every memory access go
through one of these, even if the number of fired threads is more than
that number.

v4 -> v5:
    1. Reserved a mutex lock for each cache structure; now callbacks generated
    by accesses done by different vcpus don't block each other.
    2. Used atomic increment to access hashtable entries instead of locking.
    3. Renamed mtx to hashtable_lock to reflect its job more explicitly.
    4. Dropped the usage of CoreStats, embedded stats in the cache structure.
    4. append_stats_line now takes the stats explicitly.

Mahmoud Mandour (2):
  plugins/cache: supported multicore cache modelling
  docs/devel/tcg-plugins: added cores arg to cache plugin

 contrib/plugins/cache.c    | 176 +++++++++++++++++++++++++++----------
 docs/devel/tcg-plugins.rst |  13 +--
 2 files changed, 140 insertions(+), 49 deletions(-)

-- 
2.25.1

Mahmoud Mandour <ma.mandourr@gmail.com> writes:

> Hello,
>
> This series introduce multicore cache modelling in contrib/plugins/cache.c
>
> Multi-core cache modelling is handled such that for full-system
> emulation, a private L1 cache is maintained to each core available to
> the system. For multi-threaded userspace emulation, a static number of
> cores is maintained for the overall system, and every memory access go
> through one of these, even if the number of fired threads is more than
> that number.

Queued to plugins/next, thanks.

-- 
Alex Bennée

On Tue, Aug 3, 2021 at 11:10 PM Alex Bennée <alex.bennee@linaro.org> wrote:

>
> Mahmoud Mandour <ma.mandourr@gmail.com> writes:
>
> > Hello,
> >
> > This series introduce multicore cache modelling in
> contrib/plugins/cache.c
> >
> > Multi-core cache modelling is handled such that for full-system
> > emulation, a private L1 cache is maintained to each core available to
> > the system. For multi-threaded userspace emulation, a static number of
> > cores is maintained for the overall system, and every memory access go
> > through one of these, even if the number of fired threads is more than
> > that number.
>
> Queued to plugins/next, thanks.
>
>
From what I can see from your fork, qemu/cache.c at plugins/next ·
stsquad/qemu · GitHub
<https://github.com/stsquad/qemu/blob/plugins/next/contrib/plugins/cache.c>
,
here, I think you enqueued v4 of the patches


> --
> Alex Bennée
>

Mahmoud Mandour <ma.mandourr@gmail.com> writes:

> On Tue, Aug 3, 2021 at 11:10 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  Mahmoud Mandour <ma.mandourr@gmail.com> writes:
>
>  > Hello,
>  >
>  > This series introduce multicore cache modelling in contrib/plugins/cache.c
>  >
>  > Multi-core cache modelling is handled such that for full-system
>  > emulation, a private L1 cache is maintained to each core available to
>  > the system. For multi-threaded userspace emulation, a static number of
>  > cores is maintained for the overall system, and every memory access go
>  > through one of these, even if the number of fired threads is more than
>  > that number.
>
>  Queued to plugins/next, thanks.
>
> From what I can see from your fork, qemu/cache.c at plugins/next · stsquad/qemu · GitHub, 
> here, I think you enqueued v4 of the patches

No I just haven't re-pushed the branch yet.

>  
>  -- 
>  Alex Bennée


-- 
Alex Bennée