[gem5-dev] Re: SimObject params() method
With the #include method you could have multiple params for the same
simobject. I know mid-file includes are rare, but, like goto, there are
use-cases that make sense. In this case, imo, it improves clarity.
You can just inherit from MySimObject::Params, and you aren't restricted to
doing it in any specific source file.
$cat main.cc
#include
#include
#include "MySimObject.hh"
struct FooParams : MySimObject::Params {
char foo;
};
int
main( int argc, char *argv[]){
FooParams p;
p.myint = 5;
p.foo = 'f';
MySimObject my_so_instance();
std::cout << my_so_instance.myInt() << std::endl;
return EXIT_SUCCESS;
}
Ryan Gambord
On Thu, Oct 22, 2020 at 7:58 PM Gabe Black via gem5-dev
wrote:
> [This email originated from outside of OSU. Use caution with links and
> attachments.]
> Also that (like the other mechanisms) means that there can be at most one
> C++ class for a given Params class. It would be impossible to have
> FooParams -> SimObj and BarParams -> SimObj since there is only room for
> one Params in a class.
>
> That said, we could turn the FooParams and BarParams into Params::Foo and
> Params::Bar. That would be fairly trivial, and would mean we'd only have
> one name to dodge, Params, although that's an easier name to collide with
> accidentally.
>
> I think a step in the right direction would be to start putting all our
> gem5 stuff into a gem5 namespace. Namespaces are easy to fold away in
> context (using, opening the namespace and working within it), and then we
> would only have to worry about internal collisions which I think are a lot
> easier to manage.
>
> We could even start doing that now without breaking compatibility by
> putting things in a gem5 namespace and then putting a "using namespace
> ::gem5;" at the end to maintain compatibility until we decide to switch.
>
> Gabe
>
> On Thu, Oct 22, 2020 at 7:50 PM Gabe Black wrote:
>
>> That would work, but we don't have includes in the middle of a class like
>> that anywhere else in gem5 (that I can remember at least), which I think is
>> for the best :-).
>>
>> Gabe
>>
>> On Thu, Oct 22, 2020 at 6:28 PM Gambord, Ryan via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> @Gabe Black
>>> Here is an example of what this looks like. It requires slightly
>>> modifying the boilerplate code generated for params structs, and then
>>> moving the include from the top of the source file to inside the class.
>>> This brings the struct into the class namespace.
>>>
>>> This should work fine as long as pybind can work with a FQN of an
>>> object.
>>>
>>> MySimObject.hh
>>> #ifndef __MYSIMOBJECT_HH__
>>> #define __MYSIMOBJECT_HH__
>>>
>>> class MySimObject
>>> {
>>> public:
>>> #include "MySimObjectParams.hh"
>>>
>>> public:
>>> MySimObject(Params * p) : myint(p->myint) {}
>>>
>>> int & myInt() { return myint; }
>>>
>>> private:
>>> int myint;
>>> };
>>> #endif // __MYSIMOBJECT_HH__
>>>
>>> MySimObjectParams.hh
>>> // Generated automatically by SCons //
>>>
>>> struct Params {
>>> int myint;
>>> };
>>>
>>> main.cc
>>> #include
>>> #include
>>>
>>> #include "MySimObject.hh"
>>>
>>> int
>>> main( int argc, char *argv[]){
>>> MySimObject::Params p;
>>> p.myint = 5;
>>> MySimObject my_so_instance();
>>> std::cout << my_so_instance.myInt() << std::endl;
>>> return EXIT_SUCCESS;
>>> }
>>>
>>> Ryan Gambord
>>>
>>>
>>>
>>>
>>> On Thu, Oct 22, 2020 at 5:20 PM Gabe Black via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
>>>> [This email originated from outside of OSU. Use caution with links and
>>>> attachments.]
>>>> I definitely agree that we need to use more namespaces and be better
>>>> citizens in the global namespace.
>>>>
>>>> See https://gem5.atlassian.net/browse/GEM5-730
>>>>
>>>> Mechanically, I don't think we can define something like
>>>> Mem::Ruby::Network::BasicLink::Params since that would require adding a
>>>> Params type to the not yet defined BasicLink class. You can do that with
>>>> namespaces, but not with classes. We also couldn't add a params function to
>>>> the SimObject for the same reason. Python doesn
[gem5-dev] Re: SimObject params() method
@Gabe Black
Here is an example of what this looks like. It requires slightly modifying
the boilerplate code generated for params structs, and then moving the
include from the top of the source file to inside the class. This brings
the struct into the class namespace.
This should work fine as long as pybind can work with a FQN of an object.
MySimObject.hh
#ifndef __MYSIMOBJECT_HH__
#define __MYSIMOBJECT_HH__
class MySimObject
{
public:
#include "MySimObjectParams.hh"
public:
MySimObject(Params * p) : myint(p->myint) {}
int & myInt() { return myint; }
private:
int myint;
};
#endif // __MYSIMOBJECT_HH__
MySimObjectParams.hh
// Generated automatically by SCons //
struct Params {
int myint;
};
main.cc
#include
#include
#include "MySimObject.hh"
int
main( int argc, char *argv[]){
MySimObject::Params p;
p.myint = 5;
MySimObject my_so_instance();
std::cout << my_so_instance.myInt() << std::endl;
return EXIT_SUCCESS;
}
Ryan Gambord
On Thu, Oct 22, 2020 at 5:20 PM Gabe Black via gem5-dev
wrote:
> [This email originated from outside of OSU. Use caution with links and
> attachments.]
> I definitely agree that we need to use more namespaces and be better
> citizens in the global namespace.
>
> See https://gem5.atlassian.net/browse/GEM5-730
>
> Mechanically, I don't think we can define something like
> Mem::Ruby::Network::BasicLink::Params since that would require adding a
> Params type to the not yet defined BasicLink class. You can do that with
> namespaces, but not with classes. We also couldn't add a params function to
> the SimObject for the same reason. Python doesn't define the SimObject
> class at all, even though it might look like it does because the python
> objects and C++ objects often (but not always) share the same name. The
> Python objects actually are the Params structs in C++, and then python uses
> the create method to make the actual SimObjects. The real C++ SimObject
> classes have no python analogue, although python has pointers to them and
> can indirectly call methods on them once they've been instantiated. That's
> how callbacks like init(), startup(), etc are handled.
>
> Gabe
>
> On Thu, Oct 22, 2020 at 10:25 AM Gambord, Ryan via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> While we're thinking about the params implementations, I'd also like to
>> propose that we stop cluttering the global namespace with collision-prone
>> names:
>>
>> src/.../.../MySimObject.hh
>> namespace NoClutter {
>> class MySimObject : ::SimObject
>> {
>> #include params/MySimObject.hh
>> };
>> };
>>
>> params/MySimObject.hh
>> // ... //
>> struct Params {
>> // ... //
>> };
>>
>> For example, ruby claimed the name "BasicLink", which is pretty generic.
>> Would be much better if we started moving towards
>> Mem::Ruby::Network::BasicLink::Params, which would be more idiomatic C++.
>> The params/xxx.hh sources could even include the boilerplate params()
>> method into the simobject class if you want. There is *the* canonical
>> use-case for mid-file includes -- when we have compile-time generated
>> boilerplate in separate sources.
>>
>> Right now, gem5 gives me "C with classes" vibes.
>>
>> Ryan Gambord
>>
>>
>>
>>
>> On Thu, Oct 22, 2020 at 9:18 AM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> [This email originated from outside of OSU. Use caution with links and
>>> attachments.]
>>> Another simple proposal:
>>> - Remove params() from the API (with deprecation)
>>> - Update objects that can easily be updated and remove the params()
>>> calls/casts. I think this is most cases of the params use outside of the
>>> constructor.
>>> - Don't worry about the others that use the params() function in many
>>> places that require deeper updates
>>> - Update the documentation to say that the "best practice" is to not use
>>> the param function
>>> - In the future, make sure that new objects don't store the params
>>> object.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Thu, Oct 22, 2020 at 8:51 AM Giacomo Travaglini <
>>> giacomo.travagl...@arm.com> wrote:
>>>
>>>> Let me add to the plate a simple proposal though still a bit verbose
>>>> and probably not that different from a manual cast
>>>>
>>>>
>>>>
>>>> Defining a template method in SimObject:
>>>>
>>>>
>>>>
>>>> *template *
>>>
[gem5-dev] Re: SimObject params() method
While we're thinking about the params implementations, I'd also like to
propose that we stop cluttering the global namespace with collision-prone
names:
src/.../.../MySimObject.hh
namespace NoClutter {
class MySimObject : ::SimObject
{
#include params/MySimObject.hh
};
};
params/MySimObject.hh
// ... //
struct Params {
// ... //
};
For example, ruby claimed the name "BasicLink", which is pretty generic.
Would be much better if we started moving towards
Mem::Ruby::Network::BasicLink::Params, which would be more idiomatic C++.
The params/xxx.hh sources could even include the boilerplate params()
method into the simobject class if you want. There is *the* canonical
use-case for mid-file includes -- when we have compile-time generated
boilerplate in separate sources.
Right now, gem5 gives me "C with classes" vibes.
Ryan Gambord
On Thu, Oct 22, 2020 at 9:18 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:
> [This email originated from outside of OSU. Use caution with links and
> attachments.]
> Another simple proposal:
> - Remove params() from the API (with deprecation)
> - Update objects that can easily be updated and remove the params()
> calls/casts. I think this is most cases of the params use outside of the
> constructor.
> - Don't worry about the others that use the params() function in many
> places that require deeper updates
> - Update the documentation to say that the "best practice" is to not use
> the param function
> - In the future, make sure that new objects don't store the params object.
>
> Cheers,
> Jason
>
> On Thu, Oct 22, 2020 at 8:51 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Let me add to the plate a simple proposal though still a bit verbose and
>> probably not that different from a manual cast
>>
>>
>>
>> Defining a template method in SimObject:
>>
>>
>>
>> *template *
>>
>> *Obj params()*
>>
>>
>> *{ return static_cast(_params);*
>>
>> *Or more secure:*
>>
>> *param = dynamic_cast(_params);*
>>
>> *assert(param);*
>>
>> *return param;*
>>
>> *}*
>>
>>
>>
>> And delegate the type specification on the client side:
>>
>>
>>
>> For example in my shiny new
>>
>>
>>
>> Class MyObject : public SimObject {}
>>
>>
>>
>> I would use
>>
>>
>>
>> auto p = params();
>>
>>
>>
>> You still have to type your param type so that doesn’t make it the best
>> but I believe it’s the simplest one
>>
>>
>>
>> Giacomo
>>
>>
>>
>> *From:* Jason Lowe-Power via gem5-dev
>> *Sent:* 22 October 2020 16:26
>> *To:* gem5 Developer List
>> *Cc:* Gabe Black ; Jason Lowe-Power <
>> ja...@lowepower.com>
>> *Subject:* [gem5-dev] Re: SimObject params() method
>>
>>
>>
>> Hey Gabe,
>>
>>
>>
>> Thanks for bringing this up. I have also been bothered by the lack of
>> consistency with how params are used. I can't think of an example of when
>> you need to store the params object. I would be all for getting rid of the
>> params() function and updating the documentation to say that it's best
>> practice to *not* save the params struct after the constructor. If some
>> object had a good reason to go against this best practice, that would be
>> OK, and we wouldn't need to enforce any specific design or pattern on these
>> exceptions. I would prefer to remove the params() function than add more
>> template magic.
>>
>>
>>
>> On Thu, Oct 22, 2020 at 1:18 AM Gabe Black via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>> Hi folks. I'm looking at the SimObject header, and I see a few things in
>> there which are marked as part of the API and maybe shouldn't be.
>> Specifically I'm talking about the Params typedef, and the params() method.
>> There is also the _params member variable which I can see being a part of
>> the API since it can be used by other classes to make their own params()
>> function (more on that below), but the Params typedef is more or less an
>> implementation detail, and the params() method is essentially worthless
>> because it returns a SimObjectParams which doesn't have anything except the
>> object's name in it, and you can already get that with the name() method.
>>
>>
>>
>> I agree. I think the typedef is useless and shouldn't be in the API. It's
>> unfortunate that the API proposals didn't get more reviews. I think it's
>> probably OK to just drop that from the API, but the params() function
>> itself is going to need to be deprecated.
>>
>>
>>
>>
>>
>> *Params pattern*
>>
>>
>>
>> This gets to the whole Params params() pattern which is sporadically
>> implemented in some SimObjects in gem5. This pattern is that a given
>> SimObject subclass will define a Params typedef which corresponds to its
>> Params struct type, and then also define a params() method which returns
>> the _params from SimObject cast up to that type.
>>
>>
>>
>> The Params typedef itself primarily makes the definition of the
>> constructor a little more legible, since the FullFooTypeForTheArmISAParams
>> can be really verbose.
>>
>>
>>
>> I think verbose is fine. I
[gem5-dev] Re: MessageBuffer double counting delay between arrival and dequeue ticks?
Hi Srikant, Thank you for looking into it. I noticed the miscalculation while working on something unrelated, and wasn't sure what those values were used for (I don't need them). If it's not being used, then my proposed change would be to remove it from the codebase as legacy bloat. Does anyone have a problem with that? Ryan Gambord On Mon, Sep 14, 2020 at 11:44 PM Srikant Bharadwaj via gem5-dev < gem5-dev@gem5.org> wrote: > [This email originated from outside of OSU. Use caution with links and > attachments.] > Hi Ryan, > You are right. If the message goes to the next message buffer, delay is > added again. > However, as far as I know we are not using the delayed ticks for > calculating anything anymore. The earlier use case was to calculate the > stall time within MessageBuffer, but we use the getTime to do that now. > Is there any specific use case you are trying to fix here? > > In any case, it would be great if you can post a fix. > > Thanks, > Srikant > > On Mon, Sep 14, 2020 at 10:48 AM Jason Lowe-Power via gem5-dev < > gem5-dev@gem5.org> wrote: > >> Hey Ryan, >> >> Sorry for the slow reply. Yes, it looks like delayedTicks may be double >> counting in some cases. I wonder if a little microbenchmark might be able >> to confirm more clearly? Assuming it is being double counted, we'd welcome >> a fix! >> >> @Bharadwaj, Srikant might be able to help as >> well. Srikant, did you see anything like this with Garnet 3.0? >> >> Cheers, >> Jason >> >> On Fri, Sep 11, 2020 at 2:35 AM Gambord, Ryan via gem5-dev < >> gem5-dev@gem5.org> wrote: >> >>> bump >>> >>> On Tue, Sep 1, 2020, 12:21 Gambord, Ryan >>> wrote: >>> >>>> I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue >>>> and dequeue methods. Since dequeue does not setLastEnqueueTime of the >>>> message to the time it was dequeued at, when enqueue calls >>>> UpdateDelayedTicks, doesn't it add the dequeue delay to the delayed ticks a >>>> second time? >>>> >>>> Below is a table of the timeline. X and Y are the starting values for >>>> LastEnqueueTime and DelayedTicks when the first message buffer receives the >>>> message. When the message is dequeued from MB1, DelayedTicks gets C-B added >>>> to it. When it is then enqueued in MB2, it gets D-B added, which double >>>> counts the C-B interval. >>>> >>>> curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks >>>> >>>> >>>> X Y >>>> A enqueue() B = A + Delta Y + (A-X) >>>> B wakeup() " " >>>> C dequeue() " Y + (A-X) + (C-B) >>>> D enqueue() E = D + Delta >>>> Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B) >>>> >>>> >>>> Ryan Gambord >>>> >>>> >>>> ___ >>> gem5-dev mailing list -- gem5-dev@gem5.org >>> To unsubscribe send an email to gem5-dev-le...@gem5.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> ___ >> gem5-dev mailing list -- gem5-dev@gem5.org >> To unsubscribe send an email to gem5-dev-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > ___ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] Re: MessageBuffer double counting delay between arrival and dequeue ticks?
bump On Tue, Sep 1, 2020, 12:21 Gambord, Ryan wrote: > I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue and > dequeue methods. Since dequeue does not setLastEnqueueTime of the message > to the time it was dequeued at, when enqueue calls UpdateDelayedTicks, > doesn't it add the dequeue delay to the delayed ticks a second time? > > Below is a table of the timeline. X and Y are the starting values for > LastEnqueueTime and DelayedTicks when the first message buffer receives the > message. When the message is dequeued from MB1, DelayedTicks gets C-B added > to it. When it is then enqueued in MB2, it gets D-B added, which double > counts the C-B interval. > > curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks > > > X Y > A enqueue() B = A + Delta Y + (A-X) > B wakeup() " " > C dequeue() " Y + (A-X) + (C-B) > D enqueue() E = D + Delta > Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B) > > > Ryan Gambord > > > ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[gem5-dev] MessageBuffer double counting delay between arrival and dequeue ticks?
I noticed that MessageBuffer calls UpdateDelayedTicks in both enqueue and dequeue methods. Since dequeue does not setLastEnqueueTime of the message to the time it was dequeued at, when enqueue calls UpdateDelayed Ticks, doesn't it add the dequeue delay to the delayed ticks a second time? Below is a table of the timeline. X and Y are the starting values for LastEnqueueTime and DelayedTicks when the first message buffer receives the message. When the message is dequeued from MB1, DelayedTicks gets C-B added to it. When it is then enqueued in MB2, it gets D-B added, which double counts the C-B interval. curTime() FunctionCall m_LastEnqueueTime m_DelayedTicks X Y A enqueue() B = A + Delta Y + (A-X) B wakeup() " " C dequeue() " Y + (A-X) + (C-B) D enqueue() E = D + Delta Y + (A-X) + (C-B) + (D-B) = Y + (A-X) + (C-B) + (D-C) + (C-B) Ryan Gambord ___ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
Re: [gem5-dev] [Bug report] Deprecated exception syntax in scons build files causing syntax errors
Sure, here is some diagnostic info. *ryan@rg-home ~ $git clone https://gem5.googlesource.com/public/gem5 <https://gem5.googlesource.com/public/gem5>* Cloning into 'gem5'... remote: Sending approximately 172.49 MiB ... remote: Counting objects: 127, done remote: Finding sources: 100% (127/127) remote: Total 197148 (delta 151017), reused 197119 (delta 151017) Receiving objects: 100% (197148/197148), 172.27 MiB | 32.76 MiB/s, done. Resolving deltas: 100% (151017/151017), done. *ryan@rg-home ~ $cd gem5; scons build/X86/gem5.opt -j8* *** Error loading site_init file './site_scons/site_init.py': File "./site_scons/site_init.py", line 52 except SystemExit, e: ^ SyntaxError: invalid syntax *ryan@rg-home ~/gem5 $python2.7 "$(which scons)" build/X86/gem5.opt* SCons import failed. Unable to find engine files in: /usr/lib/scons-3.1.1 /usr/lib/scons-3.1.1 /usr/local/lib/scons-3.1.1 /usr/lib/python2.7/site-packages/scons-3.1.1 /usr/lib/python2.7/site-packages/scons-3.1.1 /usr/lib/scons-3.1.1 /usr/lib/scons /usr/lib/scons /usr/local/lib/scons /usr/lib/python2.7/site-packages/scons /usr/lib/python2.7/site-packages/scons /usr/lib/scons Traceback (most recent call last): File "/usr/bin/scons", line 195, in import SCons.Script ImportError: No module named SCons.Script *ryan@rg-home ~/gem5 $which python; python -V* /usr/bin/python Python 3.7.4 *ryan@rg-home ~/gem5 $which scons; scons -v* /usr/bin/scons SCons by Steven Knight et al.: script: v3.1.1.__BUILD__, 2019-08-08 03:09:12, by none on none engine: v__VERSION__.__BUILD__, __DATE__, by __DEVELOPER__ on __BUILDSYS__ engine path: ['/usr/lib/python3.7/site-packages/SCons'] __COPYRIGHT__ On Wed, Aug 21, 2019, 09:18 Jason Lowe-Power wrote: > Hey Ryan, > > Could you give more details on your system? What python version does it > have? I thought we had dealt with the python3 issues in scons... > > Thanks, > Jason > > On Tue, Aug 20, 2019 at 6:22 PM Gambord, Ryan > wrote: > > > I recently updated my system and now I cannot build gem5 because scons > > gives the error: > > > > *** Error loading site_init file './site_scons/site_init.py': > > > File "./site_scons/site_init.py", line 52 > > > > > > except SystemExit, e: > > > > > > ^ > > > > > > SyntaxError: invalid syntax > > > > > > > Updating the syntax leads to chasing down more syntax errors further in > the > > scons build scripts. > > > > Ryan Gambord > > > > ___ > > gem5-dev mailing list > > gem5-dev@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] [Bug report] Deprecated exception syntax in scons build files causing syntax errors
I recently updated my system and now I cannot build gem5 because scons gives the error: *** Error loading site_init file './site_scons/site_init.py': > File "./site_scons/site_init.py", line 52 > > except SystemExit, e: > > ^ > > SyntaxError: invalid syntax > Updating the syntax leads to chasing down more syntax errors further in the scons build scripts. Ryan Gambord ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] include order style checker bug
I can confirm it's been doing this for a while now on my end. Lots of existing files in gem5 fail the style checker when I modify them, so it seems to be at least somewhat recent, or people were overriding the style checker in the past. Ryan Gambord On Thu, May 2, 2019, 22:58 Gabe Black wrote: > Here's another potentially related bug. There was an extra space between > the final header and the using at the top of a .cc, and the style fixer > decided to move the include of the corresponding .hh from the top where it > belonged down into the list of includes in alphabetic order. It still > complained about the headers after, but when told to fix it it made no > changes. It seems the fixer doesn't always recognize when the > .hh corresponding to a .cc needs to be at the top. > > Gabe > > On Thu, May 2, 2019 at 10:50 PM Gabe Black wrote: > > > Hey folks. I just ran into a bug in the style checker/fixer, and since I > > wanted to make sure I kept track of those so they can be fixed I thought > I > > would describe it here for the record. I have a cc file which had a > single > > system include (#include ) and the include for its .hh file > > (#include "base/loader/loader.hh"), but they were in the wrong order, > > system and then .hh. The style checker correctly complained about the > order > > and offered to fix it, but when I said yes it didn't actually change > > anything or print any messages. FYI in case somebody wants to > investigate. > > > > Gabe > > > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Gem5 Full System Crashes
It looks like the mailing list stripped out your attachment. Ryen On Thu, Apr 25, 2019, 08:47 Stefan Waczynski wrote: > Hi All, > > I have been trying to start work with gem5 Full-System simulation (my > intent is to run multiple workloads in parallel and observe interference > effects along with some OS behavior for these parallel workloads). > > I boot into the simulation using the atomic CPU model with a runtime script > who's goal is simply to checkpoint the system, and then run a primitive > benchmark a couple times--running "ls" in the home directory (I have > attached a text file with the script text). > > This works with the atomic CPU model, and it also does work when the system > being checkpointed and restored is a single-core system. Problems arise > with multi-core systems which generally crash almost-immediately upon > restore. I have two kernels that I use for this simulation--a 3.4.112 Linux > kernel, and the 2. provided on the gem5 resources website. > > With the newer kernel, the crash is a "soft crash" (usually in the middle > of a print statement) where the simulation hangs without either generating > m5 output files or trace-back information (at-least not that I can find--I > am not certain how to debug this more effectively, as I don't know what > cycle-range to look at). > > I have attached the LibC backtrace for the older kernel for reference (I > have had little success figuring it out). > > I apologize if this is the wrong mailing list for this type of question. > > Thank you in advance, > Stefan Waczynski > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Multiple inheirtance for SimObjects and Garnet networks
Jason, Thank you for taking initiative on this. I can see the point of view that some of us have regarding historic design decisions. Personally, I think that if the overhead is not an issue, then it makes sense to add this feature (which requires relatively minor changes to the codebase) even if few people want to use it -- what's the harm in having more options? The need is not super strong on my end right now -- I just came across the note about it being unsupported, and decided that building in multi-inheritance would be a good way to get my feet wet with gem5. In working on it, I did come across a few other areas of the project where it seemed to me that the authors would have liked to use multi-inheritance, and ended up having to work around the limitation, but I don't remember off the top of my head. Maybe other mailing list members can see a value for themselves and want to chime in? I think the biggest use is in copying entire class hierarchies and extending them, like I did with the garnet/simple/basic links. Ryan Gambord On Wed, Apr 3, 2019 at 9:35 AM Jason Lowe-Power wrote: > Hi all, > > I'm moving this discussion off of gerrit an onto email for now since we've > derailed from talking about the merits of this patch :). See > https://gem5-review.googlesource.com/c/public/gem5/+/17609 for the rest > of the conversation. > > @Ryan: First of all, I'd like to apologize for dropping the ball. You > contacted me a while ago about these patches and I didn't find the time to > respond. Sorry about that :). It's a deceptively complex change. > > I would like to understand better the broader need for multiple > inheritance. I can see how it helps in the Ruby network example. However, I > am concerned that there isn't a broader need for it. This is a large > conceptual change which goes against gem5's historic design decisions (as > mentioned by Gabe). So, we need to have a very strong reason for making > this change. > > Though, if there is a good reason, we should do it! If the reason for not > doing it originally was the overhead of virtual functions and compilers are > now better, then maybe it's time to revisit this design decision. > > As far as the Ruby network goes... This code was not originally part of m5 > and didn't make the same design decisions. I think this is probably why > you're having problems shoehorning new things into Garnet. I think we > should look at updating just the Garnet/Ruby network code to be more in > line with the rest of gem5 before we jump to changing gem5 for Garnet/Ruby, > if that makes sense. > > Ryan, maybe you could prepare a short document describing the > motivation/need for the changes so we can better understand the background > (e.g., see what Gabe did for the port updates recently). > > Cheers, > Jason > > On Tue, Apr 2, 2019 at 4:30 PM Gambord, Ryan > wrote: > >> That's an understandable decision. I started working on gem5 recently, so >> I'm not familiar with the history of the project (nor gerrit, etc) -- >> apologies for stepping on any toes. I can move the change to wip or abandon >> if it that's appropriate; I'm not really sure what the generally accepted >> thing to do is here. >> >> I am using multi-inheritance for a new ruby network I am working on. I >> immediately ran into the below quoted part of SimObject.py, which motivated >> me to fix multidict and enable support for multiple inheritance in the core >> files. >> >>> 485 <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#485> >>> # We don't support multiple inheritance of sim objects. If you want486 >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#486># >>> to, you must fix multidict to deal with it properly. Non sim-objects487 >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#487># >>> are ok, though488 >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#488> >>> bTotal <http://grok.gem5.org/source/s?defs=bTotal=gem5> = 0489 >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#489> >>> *for* c *in* bases >>> <http://grok.gem5.org/source/s?defs=bases=gem5>:490 >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#490> >>> *if* isinstance >>> <http://grok.gem5.org/source/s?defs=isinstance=gem5>(c, >>> MetaSimObject >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#MetaSimObject>):491 >>> <http://grok.gem5.org/xref/gem5/src/python/m5/SimObject.py#491> >>> bTotal <http://grok.gem5.org/source/s?d
