Hi Jason, Tony,

I see that you have expressed an interest (or you have been pulled in somehow 
😊) to review this patch, which has been sitting on RB for a while:

https://gem5-review.googlesource.com/c/public/gem5/+/13516

Sorry about the size, this is one of the chunkiest patches from our current 
effort of upstreaming Arm SVE support, which touches various bits of the O3CPU.

The patch is basically about bringing better support for handling wide memory 
accesses to O3CPU, as this aspect becomes more relevant when dealing with large 
vectors.

I would really appreciate if you or someone else in the list of maintainers 
could give us some feedback - at least assessing whether there are any major 
blockers with the approach taken would be very valuable at this stage.



Thanks, and sorry to be a nuisance

Giacomo



On 12/12/2018, 14:52, "gem5-dev on behalf of Giacomo Gabrielli (Gerrit)" 
<[email protected] on behalf of 
[email protected]> wrote:



    Hello Anthony Gutierrez, Jason Lowe-Power, Giacomo Travaglini,



    I'd like you to reexamine a change. Please visit



         https://gem5-review.googlesource.com/c/public/gem5/+/13516



    to look at the new patch set (#12).



    Change subject: cpu-o3: O3 LSQ Generalisation

    ......................................................................



    cpu-o3: O3 LSQ Generalisation



    This patch does a large modification of the LSQ in the O3 model. The

    main goal of the patch is to remove the 'an operation can be served with

    one or two memory requests' assumption that is present in the LSQ

    and the instruction with the req, reqLow, reqHigh triplet, and

    generalising it to operations that can be addressed with one request,

    and operations that require many requests, embodied in the

    SingleDataRequest and the SplitDataRequest.



    This modification has been done mimicking the minor model to an extent,

    shifting the responsibilities of dealing with VtoP translation and

    tracking the status and resources from the DynInst to the LSQ via the

    LSQRequest. The LSQRequest models the information concerning the

    operation, handles the creation of fragments for translation and request

    as well as assembling/splitting the data accordingly.



    With this modifications, the implementation of vector ISAs, particularly

    on the memory side, become more rich, as the new model permits a

    dissociation of the ISA characteristics as vector length, from the

    microarchitectural characteristics that govern how contiguous loads are

    executing, allowing exploration of different LSQ to DL1 bus widths to

    understand the tradeoffs in complexity and performance.



    Part of the complexities introduced stem from the fact that gem5 keeps a

    large amount of metadata regarding, in particular, memory operations,

    thus, when an instruction is squashed while some operation as TLB lookup

    or cache access is ongoing, when the relevant structure communicates to

    the LSQ that the operation is over, it tries to access some pieces of

    data that should have died when the instruction is squashed, leading to

    asserts, panics, or memory corruption. To ensure the correct behaviour,

    the LSQRequest rely on assesing who is their owner, and self-destroying

    if they detect their owner is done with the request, and there will be

    no subsequent action. For example, in the case of an instruction

    squashed whal the TLB is doing a walk to serve the translation, when the

    translation is served by the TLB, the LSQRequest detects that the

    instruction was squashed, and as the translation is done, no one else

    expect to access its information, and therefore, it self-destructs.

    Having destroyed the LSQRequest earlier, would lead to wrong behaviour

    as the TLB walk may access some fields of it.



    Additional authors:

    - Gabor Dozsa <[email protected]>



    Change-Id: I9578a1a3f6b899c390cdd886856a24db68ff7d0c

    Signed-off-by: Giacomo Gabrielli <[email protected]>

    ---

    M src/base/refcnt.hh

    M src/cpu/base_dyn_inst.hh

    M src/cpu/base_dyn_inst_impl.hh

    M src/cpu/o3/cpu.hh

    M src/cpu/o3/iew_impl.hh

    M src/cpu/o3/inst_queue_impl.hh

    M src/cpu/o3/lsq.hh

    M src/cpu/o3/lsq_impl.hh

    M src/cpu/o3/lsq_unit.hh

    M src/cpu/o3/lsq_unit_impl.hh

    M src/cpu/o3/probe/elastic_trace.cc

    11 files changed, 1,886 insertions(+), 1,274 deletions(-)





    --

    To view, visit https://gem5-review.googlesource.com/c/public/gem5/+/13516

    To unsubscribe, or for help writing mail filters, visit

    https://gem5-review.googlesource.com/settings



    Gerrit-Project: public/gem5

    Gerrit-Branch: master

    Gerrit-Change-Id: I9578a1a3f6b899c390cdd886856a24db68ff7d0c

    Gerrit-Change-Number: 13516

    Gerrit-PatchSet: 12

    Gerrit-Owner: Giacomo Gabrielli <[email protected]>

    Gerrit-Reviewer: Anthony Gutierrez <[email protected]>

    Gerrit-Reviewer: Giacomo Travaglini <[email protected]>

    Gerrit-Reviewer: Jason Lowe-Power <[email protected]>

    Gerrit-CC: Gabor Dozsa <[email protected]>

    Gerrit-MessageType: newpatchset

    _______________________________________________

    gem5-dev mailing list

    [email protected]

    http://m5sim.org/mailman/listinfo/gem5-dev

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to