Re: [gem5-dev] registerThreadContext
On 05/31/11 22:43, Steve Reinhardt wrote: > On Wed, May 25, 2011 at 10:57 AM, nathan binkert wrote: >> I see a few options for solving this problem: >> 1) Separate out the contextId allocation from registerThreadContext so >> things like DMA controllers and memtesters can get allocated a >> contextID. >> 2) Create a base class for ThreadContext that is far simpler than the >> current thread context and use that when registering. >> 3) Figure out contextID not by registration, but instead by doing a >> traversal of the memory system. This would require that we have some >> sort of indication differentiating memory objects that can generate >> requests and thus require a contextID and memory objects that can't >> (caches, dram, pio devices, etc.). We add a constructor parameter to >> the MemObject base class. >> 4) Add a separate registration function for non Thread Contexts. > While #3 sounds nice, it's a relatively big change, and would have to > be done in a way that works both for the m5 classic memory system and > for Ruby, and ideally is robust and predictable in assigning > contextIDs in the face of minor configuration changes. My guess is > that it will end up being harder than it sounds... maybe Korey can > speak up if his experience indicates otherwise. > > The others seem more reasonable, but possibly still overkill. > > The idea I had, that's kind of a hack but combines #2 and #4 in a > degenerate sort of way, would be to allow non-ThreadContext objects to > call registerThreadContext, but they would pass in NULL for the > ThreadContext pointer. This would allow something like a DMA device > or the memtester to reserve or allocate a context ID without being a > ThreadContext, but without creating an additional base class. The > only down side I see is that error tracking would be harder; if two > non-ThreadContexts tried to claim the same ID, the System would not > have a pointer to be able to identify the first one. Basically that's > the only case I can see where it would be useful for the System object > to hold on to some kind of pointer for something that's not an actual > ThreadContext. Of course, the current ThreadContext pointers don't > have any real debug info either, so even now you just get "Cannot have > two CPUs with the same id (%d)\n" when you try to reuse a context ID, > so apparently it hasn't been a big problem. > > If we cared about providing good error messages, we could extend > registerThreadContext to take both a SimObject* and a ThreadContext* > and track both of these, but make the latter optional. This would > provide better error messages for everyone (though again, this hasn't > been a problem that I've seen). registerThreadContext is only called > from one place (BaseCPU::registerThreadContexts()) so it wouldn't be > hard to change that. > > Just some ideas... > > Steve > ___ > gem5-dev mailing list > gem5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/gem5-dev One drawback I see with this sort of approach is that you have to be careful if you want to loop over all registered contexts and do something with their thread contexts. You'd have to be careful to check which ones were NULL, and if that's uncommon it might be easy to forget to do. Gabe ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] registerThreadContext
On Wed, May 25, 2011 at 10:57 AM, nathan binkert wrote: > > I see a few options for solving this problem: > 1) Separate out the contextId allocation from registerThreadContext so > things like DMA controllers and memtesters can get allocated a > contextID. > 2) Create a base class for ThreadContext that is far simpler than the > current thread context and use that when registering. > 3) Figure out contextID not by registration, but instead by doing a > traversal of the memory system. This would require that we have some > sort of indication differentiating memory objects that can generate > requests and thus require a contextID and memory objects that can't > (caches, dram, pio devices, etc.). We add a constructor parameter to > the MemObject base class. > 4) Add a separate registration function for non Thread Contexts. While #3 sounds nice, it's a relatively big change, and would have to be done in a way that works both for the m5 classic memory system and for Ruby, and ideally is robust and predictable in assigning contextIDs in the face of minor configuration changes. My guess is that it will end up being harder than it sounds... maybe Korey can speak up if his experience indicates otherwise. The others seem more reasonable, but possibly still overkill. The idea I had, that's kind of a hack but combines #2 and #4 in a degenerate sort of way, would be to allow non-ThreadContext objects to call registerThreadContext, but they would pass in NULL for the ThreadContext pointer. This would allow something like a DMA device or the memtester to reserve or allocate a context ID without being a ThreadContext, but without creating an additional base class. The only down side I see is that error tracking would be harder; if two non-ThreadContexts tried to claim the same ID, the System would not have a pointer to be able to identify the first one. Basically that's the only case I can see where it would be useful for the System object to hold on to some kind of pointer for something that's not an actual ThreadContext. Of course, the current ThreadContext pointers don't have any real debug info either, so even now you just get "Cannot have two CPUs with the same id (%d)\n" when you try to reuse a context ID, so apparently it hasn't been a big problem. If we cared about providing good error messages, we could extend registerThreadContext to take both a SimObject* and a ThreadContext* and track both of these, but make the latter optional. This would provide better error messages for everyone (though again, this hasn't been a problem that I've seen). registerThreadContext is only called from one place (BaseCPU::registerThreadContexts()) so it wouldn't be hard to change that. Just some ideas... Steve ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Functional Memory Accesses in Ruby
On Sat, 28 May 2011, Nilay Vaish wrote: Hi Brad I am trying to complete the patch on functional accesses in Ruby. I came across this problem while testing the patch for higher number of processors. I am working with MESI CMP directory protocol right now. So I will describe the problem in its context. Assume we are trying to functionally write some thing to block A. It is in state S_I in the L2 cache. When a block moves to state S_I from state SS, then the cache block in the cache is deallocated. Therefore, when viewed from the CacheMemory's perpespective, since the cache does not have block A, therefore, the L2 cache is of no consequence for this access. But the controller has a TBE for this block. And this TBE will have this block with AccessPermission:Busy. Also, there are L1 caches in the system that hold this block in S state. Now, as per the current condition for write functional accesses, if((num_busy == 0 && num_ro > 0) || num_rw == 1) this access would go ahead as num_busy would evaluate to 0 and num_ro would evaluate to some value greater than 0. But clearly we do not want this access to be performed since that state S_I is a busy state and no other cache holds the block in a read-write state. It seems to me that the controller should supply the function for deciding the access permissions, since it is possible that one the TBE holds the block. -- Nilay Brad, I went over the discussion that we had this morning. I think the getState() function cannot be used for extracting access permissions. This is because the getState() function needs pouinters to transaction buffer and cache entries, apart from the address. I think we should let the Controller provide a function for getting the access permissions. This function would be a virtual function declared in the AbstractController class, but would not be pure. The AbstractController implementation of the function would always return busy, so that functional accesses are not enabled at all for protocols that do not provide such a function. -- Nilay ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in web-graphics: Resize topology figure
changeset c1a85b596072 in /z/repo/web-graphics details: web-graphics?cmd=changeset;node=c1a85b596072 description: Resize topology figure diffstat: ruby/figures/Topology_overview.jpg |0 1 files changed, 0 insertions(+), 0 deletions(-) diffs (2 lines): diff -r 8b47475cd2b3 -r c1a85b596072 ruby/figures/Topology_overview.jpg Binary file ruby/figures/Topology_overview.jpg has changed ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] changeset in web-graphics: network: updated topology figure
changeset 8b47475cd2b3 in /z/repo/web-graphics details: web-graphics?cmd=changeset;node=8b47475cd2b3 description: network: updated topology figure diffstat: ruby/figures/Topology_overview.jpg |0 1 files changed, 0 insertions(+), 0 deletions(-) diffs (2 lines): diff -r 1f62f3ea6275 -r 8b47475cd2b3 ruby/figures/Topology_overview.jpg Binary file ruby/figures/Topology_overview.jpg has changed ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Unable to upload figures to wiki
On Tue, 31 May 2011 14:46:37 -0400, Tushar Krishna wrote: Thanks Ali. This is the repo right? h...@m5sim.org/web-graphics Yes And how do I point to the images in the repo from the wiki? http://www.gem5.org/graphics Ali ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Unable to upload figures to wiki
Thanks Ali. This is the repo right? h...@m5sim.org/web-graphics And how do I point to the images in the repo from the wiki? Thanks, Tushar On 5/31/2011 2:13 PM, Ali Saidi wrote: Upload graphics using the repository not the wiki interface. Thanks, Ali On Tue, 31 May 2011 13:41:48 -0400, Tushar Krishna wrote: Hi Nate, I am unable to upload new figures to the wiki. I get this upload warning: The upload directory (public) is not writable by the webserver. Does this have something to do with permissions? Thanks, Tushar ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Unable to upload figures to wiki
Upload graphics using the repository not the wiki interface. Thanks, Ali On Tue, 31 May 2011 13:41:48 -0400, Tushar Krishna wrote: Hi Nate, I am unable to upload new figures to the wiki. I get this upload warning: The upload directory (public) is not writable by the webserver. Does this have something to do with permissions? Thanks, Tushar ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Unable to upload figures to wiki
Hi Nate, I am unable to upload new figures to the wiki. I get this upload warning: The upload directory (public) is not writable by the webserver. Does this have something to do with permissions? Thanks, Tushar ___ gem5-dev mailing list gem5-dev@m5sim.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Cron /z/m5/regression/do-regression quick
scons: `build/ALPHA_SE/m5.debug' is up to date. scons: `build/ALPHA_SE_MOESI_hammer/m5.debug' is up to date. scons: `build/ALPHA_SE_MESI_CMP_directory/m5.debug' is up to date. scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.debug' is up to date. scons: `build/ALPHA_SE_MOESI_CMP_token/m5.debug' is up to date. scons: `build/ALPHA_FS/m5.debug' is up to date. scons: `build/MIPS_SE/m5.debug' is up to date. scons: `build/POWER_SE/m5.debug' is up to date. scons: `build/SPARC_SE/m5.debug' is up to date. scons: `build/SPARC_FS/m5.debug' is up to date. scons: `build/X86_SE/m5.debug' is up to date. scons: `build/X86_FS/m5.debug' is up to date. scons: `build/ARM_SE/m5.debug' is up to date. scons: `build/ARM_FS/m5.debug' is up to date. scons: `build/ALPHA_SE/m5.fast' is up to date. scons: `build/ALPHA_SE_MOESI_hammer/m5.fast' is up to date. scons: `build/ALPHA_SE_MESI_CMP_directory/m5.fast' is up to date. scons: `build/ALPHA_SE_MOESI_CMP_directory/m5.fast' is up to date. scons: `build/ALPHA_SE_MOESI_CMP_token/m5.fast' is up to date. scons: `build/ALPHA_FS/m5.fast' is up to date. scons: `build/MIPS_SE/m5.fast' is up to date. scons: `build/POWER_SE/m5.fast' is up to date. scons: `build/SPARC_SE/m5.fast' is up to date. scons: `build/SPARC_FS/m5.fast' is up to date. scons: `build/X86_SE/m5.fast' is up to date. scons: `build/X86_FS/m5.fast' is up to date. scons: `build/ARM_SE/m5.fast' is up to date. scons: `build/ARM_FS/m5.fast' is up to date. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linu
Re: [gem5-dev] Review Request: ISA parser: Simplify operand type handling.
On 05/30/11 21:57, Steve Reinhardt wrote:
> On Mon, May 30, 2011 at 1:33 PM, Gabe Black wrote:
>> On 05/30/11 09:47, Steve Reinhardt wrote:
>>> Anyway, it seems very odd to have to say "(int8_t)Mem.ub" when we already
>>> have a ".sb" operand type defined as "int8_t". It seems like a weird
>>> hidden restriction to say that there are operand types you can declare but
>>> can't use on memory, and that you're pushing a somewhat arbitrary internal
>>> implementation decision up to the level of language visibility, which is
>>> going the wrong direction. I'm not sure what the right solution is, but
>>> even if it's the brute force one of creating a bunch more read/write
>>> function templates in the CPU implementations, I think that's preferable.
>> [...]
>>
>> The unsigned thing is sort of a weird gotcha. I'd like to avoid adding a
>> lot of bulk to the CPU models since they're already fairly chunky and it
>> makes them harder to reason about looking through the code, but it would
>> be great to straighten this out. One possibility might be the technique
>> I used with the endianness changing functions in src/sim/byteswap.hh.
>> Things are built up in layers there:
>> [...]
> I think some kind of additional set of template instantiations should
> do it. I just noticed that we already have:
>
> template<>
> Fault
> AtomicSimpleCPU::read(Addr addr, int32_t &data, unsigned flags)
> {
> return read(addr, (uint32_t&)data, flags);
> }
>
> template<>
> Fault
> AtomicSimpleCPU::write(int32_t data, Addr addr, unsigned flags, uint64_t *res)
> {
> return write((uint32_t)data, addr, flags, res);
> }
>
> .. and similar for TimingSimpleCPU; do we just need to extend these to
> int8_t and int16_t, and maybe add similar sets in
> base_dynamic_inst.hh?
>
> Steve
> ___
> gem5-dev mailing list
> gem5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/gem5-dev
Oh yeah, I guess we're already doing something like that, and that glob
of code was just instantiating different versions of the function. Could
we reduce the amount of text by moving it into the header? There isn't a
lot of actual information there in all that text, and we're talking
about doubling it. I don't have a better idea, though.
Gabe
___
gem5-dev mailing list
gem5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/gem5-dev
