Re: [m5-dev] X86 FS regression

Tue, 23 Nov 2010 07:19:20 -0800
Where are you connecting the table walker? If it's between the l1 and l2 my guess is that it will work. if it is to the memory bus, yes, memory is just responding without the help of a cache and this could be the reason. 

Ali



On Tue, 23 Nov 2010 06:29:20 -0500, Gabe Black <[email protected]> 
wrote:

I think I may have just now. I've fixed a few issues, and am now 
getting
to the point where something that should be in the pagetables is 
causing
a page fault. I found where the table walker is walking the tables 
for
this particular access, and the last level entry is all 0s. There 
could

be a number of reasons this is all 0s, but since the main difference
other than timing between this and a working configuration is the
presence of caches and we've identified a potential issue there, I'm

inclined to suspect the actual page table entry is still in the L1 
and

hasn't been evicted out to memory yet.


To fix this, is the best solution to add a bus below the CPU for all 
the
connections that need to go to the L1? I'm assuming they'd all go 
into

the dcache since they're more data-ey and that keeps the icache read

only (ignoring SMC issues), and the dcache is probably servicing 
lower

bandwidth normally. It also seems a little strange that this type of
configuration is going on in the BaseCPU.py SimObject python file and
not a configuration file, but I could be convinced there's a reason.

Even if this isn't really a "fix" or the "right thing" to do, I'd 
still

like to try it temporarily at least to see if it corrects the problem
I'm seeing.

Gabe

Ali Saidi wrote:


I haven't seen any strange behavior yet. That isn't to say it's not

going to cause an issue in the future, but we've taken many a tlb 
miss

and it hasn't fallen over yet.

Ali


On Mon, 22 Nov 2010 13:08:13 -0800, Steve Reinhardt 
<[email protected]>

wrote:


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 <[email protected]
<mailto:[email protected]>> 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
    >> [email protected] <mailto:[email protected]>
    >> http://m5sim.org/mailman/listinfo/m5-dev
    >>
    >>
    >
    > _______________________________________________
    > m5-dev mailing list
    > [email protected] <mailto:[email protected]>
    > http://m5sim.org/mailman/listinfo/m5-dev
    >

    _______________________________________________
    m5-dev mailing list
    [email protected] <mailto:[email protected]>
    http://m5sim.org/mailman/listinfo/m5-dev






------------------------------------------------------------------------

_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev



_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev


_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev























					Reply via email to