Sorry if you receive this twice, it didn't seem to show up in the email box first time through.
---------- Forwarded message ---------- From: Malek Musleh <[email protected]> Date: Tue, Sep 13, 2011 at 4:05 PM Subject: Ruby Request Default Access Mode Type is always Supervisor? To: gem5 users mailing list <[email protected]> Hi, I have a question about the creation of Ruby Requests. It seems that when a ruby request is created in the recvTiming() of RubyPorts, it creates the request with the RubyAccessMode_Supervisor Attribute by default. RubyPort::recvTiming(): RubyRequest ruby_request(pkt->getAddr(), pkt->getPtr<uint8_t>(true), pkt->getSize(), pc, type, RubyAccessMode_Supervisor, pkt); Is there a reason for this? Before the request actually gets injected into the L1 cache by the sequencer (it again checks for the accessmode type) Sequencer::issueRequest(): RubyAccessMode amtype = RubyAccessMode_NUM; switch(request.m_AccessMode){ case RubyAccessMode_User: amtype = RubyAccessMode_User; break; case RubyAccessMode_Supervisor: amtype = RubyAccessMode_Supervisor; break; case RubyAccessMode_Device: amtype = RubyAccessMode_User; break; default: assert(0); } So in fact, this switch case becomes unnecessary if all the packets have SupervisorAccess mode. Shouldn't the access mode be actually determined by whether or not the original request of the M5 packet is from a user space application versus OS function? To clarify, shouldn't it be that before a packet is transmitted from the CPU model to the RubyPort, a function call to TheISA::InuserMode(ThreadContext *tc) should be made, a packet field then be set indicating whether or not this is a user space app Packet, or not, such that this field can be checked upon creation of the Ruby Request. I ask, because I am interested in filtering out memory accesses caused by the kernel, and look at only those caused by my benchmarks (both in the case of micro and macrobenchmarks). In the case of a full benchmark, I assume that a very small % (~1%) of accesses are from servicing systemcalls, but for a microbenchmark, there would be more reason to believe that the output statistics can be inflated. Malek _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
