From: "Alex Bennée" <alex.bennee@linaro.org>
To: Mahmoud Mandour <ma.mandourr@gmail.com>
Cc: Alexandre Iooss <erdnaxe@crans.org>, qemu-devel@nongnu.org
Subject: Re: [PATCH 2/5] plugins/cache: implement unified L2 cache emulation
Date: Fri, 08 Oct 2021 16:44:49 +0100 [thread overview]
Message-ID: <871r4vcy2m.fsf@linaro.org> (raw)
In-Reply-To: <20210810134844.166490-3-ma.mandourr@gmail.com>
Mahmoud Mandour <ma.mandourr@gmail.com> writes:
> This adds an implementation of a simple L2 configuration, in which a
> unified L2 cache (stores both blocks of instructions and data) is
> maintained for each core separately, with no inter-core interaction
> taken in account. The L2 cache is used as a backup for L1 and is only
> accessed if the wanted block does not exist in L1.
>
> In terms of multi-threaded user-space emulation, the same approximation
> of L1 is done, a static number of caches is maintained, and each and
> every memory access initiated by a thread will have to go through one of
> the available caches.
>
> An atomic increment is used to maintain the number of L2 misses per
> instruction.
>
> The default cache parameters of L2 caches is:
>
> 2MB cache size
> 16-way associativity
> 64-byte blocks
>
> Signed-off-by: Mahmoud Mandour <ma.mandourr@gmail.com>
> ---
> contrib/plugins/cache.c | 256 +++++++++++++++++++++++++++-------------
> 1 file changed, 175 insertions(+), 81 deletions(-)
>
> diff --git a/contrib/plugins/cache.c b/contrib/plugins/cache.c
> index a255e26e25..908c967a09 100644
> --- a/contrib/plugins/cache.c
> +++ b/contrib/plugins/cache.c
> @@ -82,8 +82,9 @@ typedef struct {
> char *disas_str;
> const char *symbol;
> uint64_t addr;
> - uint64_t dmisses;
> - uint64_t imisses;
> + uint64_t l1_dmisses;
> + uint64_t l1_imisses;
> + uint64_t l2_misses;
> } InsnData;
>
> void (*update_hit)(Cache *cache, int set, int blk);
> @@ -93,15 +94,20 @@ void (*metadata_init)(Cache *cache);
> void (*metadata_destroy)(Cache *cache);
>
> static int cores;
> -static Cache **dcaches, **icaches;
> +static Cache **l1_dcaches, **l1_icaches;
> +static Cache **l2_ucaches;
>
> -static GMutex *dcache_locks;
> -static GMutex *icache_locks;
> +static GMutex *l1_dcache_locks;
> +static GMutex *l1_icache_locks;
> +static GMutex *l2_ucache_locks;
Did you experiment with keeping a single locking hierarchy? I measured
quite a high contention with perf while running on system emulation.
While splitting locks can reduce contention I suspect the pattern of
access might just lead to 2 threads serialising twice in a row and
therfore adding to latency.
It might be overly complicated by the current split between i and d
cache for layer 1 which probably makes sense.
Otherwise looks reasonable to me:
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
--
Alex Bennée
next prev parent reply other threads:[~2021-10-08 15:54 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-10 13:48 [PATCH 0/5] plugins/cache: L2 cache modelling and a minor leak fix Mahmoud Mandour
2021-08-10 13:48 ` [PATCH 1/5] plugins/cache: freed heap-allocated mutexes Mahmoud Mandour
2021-10-08 14:45 ` Alex Bennée
2021-08-10 13:48 ` [PATCH 2/5] plugins/cache: implement unified L2 cache emulation Mahmoud Mandour
2021-10-08 15:44 ` Alex Bennée [this message]
2021-08-10 13:48 ` [PATCH 3/5] plugins/cache: split command line arguments into name and value Mahmoud Mandour
2021-10-08 14:05 ` Alex Bennée
2021-08-10 13:48 ` [PATCH 4/5] plugins/cache: make L2 emulation optional through args Mahmoud Mandour
2021-08-10 13:48 ` [PATCH 5/5] docs/tcg-plugins: add L2 arguments to cache docs Mahmoud Mandour
2021-08-10 14:56 ` [PATCH 0/5] plugins/cache: L2 cache modelling and a minor leak fix Mahmoud Mandour
2021-09-20 15:26 ` Mahmoud Mandour
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=871r4vcy2m.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=erdnaxe@crans.org \
--cc=ma.mandourr@gmail.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.