Hi George,
For the tagged prefetcher, I believe this is a bug in the current
implementation. I hit this a few weeks ago on ARM. For ARM (assuming X86
is the same), hardware page table walk requests are not assigned a thread
ID. When generating prefetches, the tagged prefetcher attempts to tag the
generated prefetches with the thread ID of the triggering request. Since
there is none, you get this assert when trying to read it. For now you
could fix this by simply guarding the thread setting like so:
if (pkt->req->hasContextId()) {
pf_req->setThreadContext(pkt->req->contextId(),
pkt->req->threadId());
}
This fix will probably make its way out with some other prefetcher changes
eventually. You don't see this same issue with the StridePrefetcher
because it requires a packet to have an associated PC, which guarantees
there is also a thread id. I guess the tagged prefetcher was mostly tested
out on SE (where there are no page table walks).
For the other issue, if you are simulating a large system, then just
increase the Max_Contexts. This was just sized to be larger than what most
would simulate.
On Thu, Sep 4, 2014 at 3:21 PM, George Michelogiannakis via gem5-users <
[email protected]> wrote:
> Hello everyone,
>
> I tried using the pre fetchers already in Gem5 (mostly stride and tagged)
> next to the L2 in the simple cache model (no Ruby) with just L1s and a
> single L2. From past emails I figured this should be supported, but I'm
> getting assertion failures in regards to the number of contexts the pre
> fetchers have been set for. So I just want to make sure firstly how to
> increase the contexts (I only see the default initialization of
> "Max_Contexts" to 64) and if there is any issues with using pre fetchers in
> the LLC. This is with gem5-dev and stable.
>
> The assertion:
>
> gem5.opt: build/X86_MESI_Two_Level/mem/cache/prefetch/stride.cc:66:
> virtual void StridePrefetcher::calculatePrefetch(Packet*&, std::list<long
> unsigned int>&, std::list<Cycles>&): Assertion `master_id < Max_Contexts'
> failed.
>
> For tagged, it's a little different: gem5.opt:
> build/X86_MESI_Two_Level/mem/request.hh:575: int Request::threadId() const:
> Assertion `privateFlags.isSet(VALID_THREAD_ID)' failed
>
> Perhaps it has something to do with the thread ID propagating properly to
> the prefetcher.
>
> I enable prefetchers by:
>
> system.l2 = l2_cache_class(clk_domain=system.cpu_clk_domain,
> size=options.l2_size,
> assoc=options.l2_assoc)
>
> system.l2.prefetch_on_access = 'true'
> system.l2.prefetcher = StridePrefetcher(degree=8, latency=1)
>
> (this is for the stride prefetcher case in common/CacheConfig.py).
>
>
> Thank you!
> George M
>
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
