Yea, I just got around to reading this thread and that was the point I was
going to make... the L1 cache effectively serves as a translator between the
CPU's word-size read & write requests and the coherent block-level requests
that get snooped.  If you attach a CPU-like device (such as the table
walker) directly to an L2, the CPU-like accesses that go to the L2 will get
sent to the L1s but I'm not sure they'll be handled correctly.  Not that
they fundamentally couldn't, this just isn't a configuration we test so it's
likely that there are problems... for example, the L1 may try to hand
ownership to the requester but the requester won't recognize that and things
will break.

Steve

On Mon, Nov 22, 2010 at 12:00 PM, Gabe Black <gbl...@eecs.umich.edu> wrote:

> What happens if an entry is in the L1 but not the L2?
>
> Gabe
>
> Ali Saidi wrote:
> > Between the l1 and l2 caches seems like a good place to me. The caches
> can cache page table entries, otherwise a tlb miss would be even more
> expensive then it is. The l1 isn't normally used for such things since it
> would get polluted (look why sparc has a load 128bits from l2, do not
> allocate into l1 instruction).
> >
> > Ali
> >
> > On Nov 22, 2010, at 4:27 AM, Gabe Black wrote:
> >
> >
> >>    For anybody waiting for an x86 FS regression (yes, I know, you can
> >> all hardly wait, but don't let this spoil your Thanksgiving) I'm getting
> >> closer to having it working, but I've discovered some issues with the
> >> mechanisms behind the --caches flag with fs.py and x86. I'm surprised I
> >> never thought to try it before. It also brings up some questions about
> >> where the table walkers should be hooked up in x86 and ARM. Currently
> >> it's after the L1, if any, but before the L2, if any, which seems wrong
> >> to me. Also caches don't seem to propagate requests upwards to the CPUs
> >> which may or may not be an issue. I'm still looking into that.
> >>
> >> Gabe
> >> _______________________________________________
> >> m5-dev mailing list
> >> m5-dev@m5sim.org
> >> http://m5sim.org/mailman/listinfo/m5-dev
> >>
> >>
> >
> > _______________________________________________
> > m5-dev mailing list
> > m5-dev@m5sim.org
> > http://m5sim.org/mailman/listinfo/m5-dev
> >
>
> _______________________________________________
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Reply via email to