gem5-users@gem5.org

The gem5 Users mailing list

View all threads

TLB statistics riscv

MM
Mirco Mannino
Wed, Oct 18, 2023 8:39 AM

Hi all,

I am looking at how the TLB is implemented (riscv ISA). In particular, I
am interested in TLB statistics.

I noticed that, in the TLB::lokup method
(https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109),
there is an input argument (i.e., hidden) which determines whether the
TLB lookup should or should not update TLB statistics.

In the TLB::doTranslate
(https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278)
method, the first lookup updates TLB statistics (i.e., hidden=false).
After a TLB miss, the page walker is invoked and the TLB is looked up
again in the same way.

The source code is the following:

TlbEntry *e = lookup(vaddr, satp.asid, mode, false);
    if (!e) {
        Fault fault = walker->start(tc, translation, req, mode);
        if (translation != nullptr || fault != NoFault) {
            // This gets ignored in atomic mode.
            delayed = true;
            return fault;
        }
        e = lookup(vaddr, satp.asid, mode, false);
        assert(e != nullptr);
    }

I was wondering if this behavior is correct.
Shouldn't we just count the first TLB miss and use the second TLB access
only to check the correctness of the page walker? Also because surely
the second TLB lookup will definitely result in a TLB hit, otherwise the
simulation is interrupted by an assert.

Thanks in advance,
Mirco

Hi all, I am looking at how the TLB is implemented (riscv ISA). In particular, I am interested in TLB statistics. I noticed that, in the TLB::lokup method (https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109), there is an input argument (i.e., hidden) which determines whether the TLB lookup should or should not update TLB statistics. In the TLB::doTranslate (https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278) method, the first lookup updates TLB statistics (i.e., hidden=false). After a TLB miss, the page walker is invoked and the TLB is looked up again in the same way. The source code is the following: TlbEntry *e = lookup(vaddr, satp.asid, mode, *false*);     if (!e) {         Fault fault = walker->start(tc, translation, req, mode);         if (translation != nullptr || fault != NoFault) {             // This gets ignored in atomic mode.             delayed = true;             return fault;         }         e = lookup(vaddr, satp.asid, mode, *false*);         assert(e != nullptr);     } I was wondering if this behavior is correct. Shouldn't we just count the first TLB miss and use the second TLB access only to check the correctness of the page walker? Also because surely the second TLB lookup will definitely result in a TLB hit, otherwise the simulation is interrupted by an assert. Thanks in advance, Mirco
HP
Harshil Patel
Wed, Oct 18, 2023 11:02 PM

Hi Micro,
This could be a potential bug in the code. I have opened an issue on the
gem5 github based on the above email. The link to the issue is the
following: https://github.com/gem5/gem5/issues/484

Regards,
Harshil Patel

On Wed, Oct 18, 2023 at 1:40 AM Mirco Mannino via gem5-users <
gem5-users@gem5.org> wrote:

Hi all,

I am looking at how the TLB is implemented (riscv ISA). In particular, I
am interested in TLB statistics.

I noticed that, in the TLB::lokup method (
https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109),
there is an input argument (i.e., hidden) which determines whether the TLB
lookup should or should not update TLB statistics.

In the TLB::doTranslate (
https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278)
method, the first lookup updates TLB statistics (i.e., hidden=false).
After a TLB miss, the page walker is invoked and the TLB is looked up
again in the same way.

The source code is the following:

TlbEntry *e = lookup(vaddr, satp.asid, mode, false);
if (!e) {
Fault fault = walker->start(tc, translation, req, mode);
if (translation != nullptr || fault != NoFault) {
// This gets ignored in atomic mode.
delayed = true;
return fault;
}
e = lookup(vaddr, satp.asid, mode, false);
assert(e != nullptr);
}

I was wondering if this behavior is correct.
Shouldn't we just count the first TLB miss and use the second TLB access
only to check the correctness of the page walker? Also because surely the
second TLB lookup will definitely result in a TLB hit, otherwise the
simulation is interrupted by an assert.

Thanks in advance,
Mirco


gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-leave@gem5.org

Hi Micro, This could be a potential bug in the code. I have opened an issue on the gem5 github based on the above email. The link to the issue is the following: https://github.com/gem5/gem5/issues/484 Regards, Harshil Patel On Wed, Oct 18, 2023 at 1:40 AM Mirco Mannino via gem5-users < gem5-users@gem5.org> wrote: > Hi all, > > I am looking at how the TLB is implemented (riscv ISA). In particular, I > am interested in TLB statistics. > > I noticed that, in the TLB::lokup method ( > https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109), > there is an input argument (i.e., hidden) which determines whether the TLB > lookup should or should not update TLB statistics. > > In the TLB::doTranslate ( > https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278) > method, the first lookup updates TLB statistics (i.e., hidden=false). > After a TLB miss, the page walker is invoked and the TLB is looked up > again in the same way. > > The source code is the following: > > TlbEntry *e = lookup(vaddr, satp.asid, mode, *false*); > if (!e) { > Fault fault = walker->start(tc, translation, req, mode); > if (translation != nullptr || fault != NoFault) { > // This gets ignored in atomic mode. > delayed = true; > return fault; > } > e = lookup(vaddr, satp.asid, mode, *false*); > assert(e != nullptr); > } > > > I was wondering if this behavior is correct. > Shouldn't we just count the first TLB miss and use the second TLB access > only to check the correctness of the page walker? Also because surely the > second TLB lookup will definitely result in a TLB hit, otherwise the > simulation is interrupted by an assert. > > Thanks in advance, > Mirco > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-leave@gem5.org >
MM
Mirco Mannino
Thu, Oct 19, 2023 8:39 AM

Hi Harshil,

Thanks for your reply.

Regards,

Mirco

Il 19/10/23 01:02, Harshil Patel via gem5-users ha scritto:

Hi Micro,
This could be a potential bug in the code. I have opened an issue on
the gem5 github based on the above email. The link to the issue is the
following: https://github.com/gem5/gem5/issues/484

Regards,
Harshil Patel

On Wed, Oct 18, 2023 at 1:40 AM Mirco Mannino via gem5-users
gem5-users@gem5.org wrote:

 Hi all,

 I am looking at how the TLB is implemented (riscv ISA). In
 particular, I am interested in TLB statistics.

 I noticed that, in the TLB::lokup method
 (https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109),
 there is an input argument (i.e., hidden) which determines whether
 the TLB lookup should or should not update TLB statistics.

 In the TLB::doTranslate
 (https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278)
 method, the first lookup updates TLB statistics (i.e., hidden=false).
 After a TLB miss, the page walker is invoked and the TLB is looked
 up again in the same way.

 The source code is the following:

 TlbEntry *e = lookup(vaddr, satp.asid, mode, *false*);
     if (!e) {
         Fault fault = walker->start(tc, translation, req, mode);
         if (translation != nullptr || fault != NoFault) {
             // This gets ignored in atomic mode.
             delayed = true;
             return fault;
         }
         e = lookup(vaddr, satp.asid, mode, *false*);
         assert(e != nullptr);
     }


 I was wondering if this behavior is correct.
 Shouldn't we just count the first TLB miss and use the second TLB
 access only to check the correctness of the page walker? Also
 because surely the second TLB lookup will definitely result in a
 TLB hit, otherwise the simulation is interrupted by an assert.

 Thanks in advance,
 Mirco
 _______________________________________________
 gem5-users mailing list -- gem5-users@gem5.org
 To unsubscribe send an email to gem5-users-leave@gem5.org

gem5-users mailing list --gem5-users@gem5.org
To unsubscribe send an email togem5-users-leave@gem5.org

Hi Harshil, Thanks for your reply. Regards, Mirco Il 19/10/23 01:02, Harshil Patel via gem5-users ha scritto: > Hi Micro, > This could be a potential bug in the code. I have opened an issue on > the gem5 github based on the above email. The link to the issue is the > following: https://github.com/gem5/gem5/issues/484 > > Regards, > Harshil Patel > > On Wed, Oct 18, 2023 at 1:40 AM Mirco Mannino via gem5-users > <gem5-users@gem5.org> wrote: > > Hi all, > > I am looking at how the TLB is implemented (riscv ISA). In > particular, I am interested in TLB statistics. > > I noticed that, in the TLB::lokup method > (https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L109), > there is an input argument (i.e., hidden) which determines whether > the TLB lookup should or should not update TLB statistics. > > In the TLB::doTranslate > (https://github.com/gem5/gem5/blob/stable/src/arch/riscv/tlb.cc#L278) > method, the first lookup updates TLB statistics (i.e., hidden=false). > After a TLB miss, the page walker is invoked and the TLB is looked > up again in the same way. > > The source code is the following: > > TlbEntry *e = lookup(vaddr, satp.asid, mode, *false*); >     if (!e) { >         Fault fault = walker->start(tc, translation, req, mode); >         if (translation != nullptr || fault != NoFault) { >             // This gets ignored in atomic mode. >             delayed = true; >             return fault; >         } >         e = lookup(vaddr, satp.asid, mode, *false*); >         assert(e != nullptr); >     } > > > I was wondering if this behavior is correct. > Shouldn't we just count the first TLB miss and use the second TLB > access only to check the correctness of the page walker? Also > because surely the second TLB lookup will definitely result in a > TLB hit, otherwise the simulation is interrupted by an assert. > > Thanks in advance, > Mirco > _______________________________________________ > gem5-users mailing list -- gem5-users@gem5.org > To unsubscribe send an email to gem5-users-leave@gem5.org > > > _______________________________________________ > gem5-users mailing list --gem5-users@gem5.org > To unsubscribe send an email togem5-users-leave@gem5.org