Re: [m5-dev] Checkpointing

[Steve Reinhardt]

On Sun, Mar 27, 2011 at 1:27 PM, nathan binkert  wrote:
>> Is there any reason to have a serialize function in the timing and o3 cpus? 
>> Creating a checkpoint from them will be broken since if you're using cache 
>> the dirty data won't be saved? Shouldn't we change their implementation to 
>> fatal()?
>
> Is the implementation of the CPUs correct?  Arguably, it should be the
> caches that cause fatal() if they're what cause the problem, no?

I agree with Nate... in fact the Ruby caches do have a warm-up
facility that Brad is working on porting (or says he will), so we
don't want to assume that caches can't be checkpointed.  Also it's
possible to have a timing CPU with no caches (even though it doesn't
make a lot of sense).

What I would like to see is to have the O3 unserialize function fixed
so that we can avoid the silly switch_cpus thing when you want to
restore directly into O3... at least my understanding is that that's
why we don't do it that way.

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing

[nathan binkert]

> Is there any reason to have a serialize function in the timing and o3 cpus? 
> Creating a checkpoint from them will be broken since if you're using cache 
> the dirty data won't be saved? Shouldn't we change their implementation to 
> fatal()?

Is the implementation of the CPUs correct?  Arguably, it should be the
caches that cause fatal() if they're what cause the problem, no?

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Checkpointing

[Ali Saidi]

Is there any reason to have a serialize function in the timing and o3 cpus? 
Creating a checkpoint from them will be broken since if you're using cache the 
dirty data won't be saved? Shouldn't we change their implementation to fatal()?

Thanks,
Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[nathan binkert]

>> Did we ever write down what those changes were?  I recall that
>> discussion but not the details, and a quick search of my email didn't
>> turn anything up.
>
> No.  I think I remember most of the details.  I'll try to throw
> together a wiki page.

Ok.  Here it is.  It's mostly a brain dump without fully thinking
things through or coming up with a plan.  That said, I don't think it
will be too bad.
http://m5sim.org/wiki/index.php/Serialization_Ideas

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[Gabe Black]

nathan binkert wrote:
>> We do have the Serializable class and could track all the instances of
>> that.  One question is whether there's enough overhead in SimObjects
>> that we really need a lighter-weight class to support these cases.
>> 
>
> Well, SimObjects have a Python component and must be described in at
> least two files.  I think there's a fair amount of extra overhead.
> One thing though is that there are certain objects like the
> EthPacketData that we wouldn't want to have to get onto and off of the
> global serialization list and will still want to serialize manually.
> I personally would rather not make things SimObjects that nobody will
> ever mess with.  Alternatively, we could differentiate a Python
> exposed SimObject from a C++ only SimObject. and fold Serializable
> into the latter.
>
> Perhaps we could figure out if we (or Joel :) could somewhat quickly
> implement some of the Serialization changes that we discussed.
>
>   Nate
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>   

In this particular case the mouse/keyboard objects are just stubs to
give Linux something to poke at to its satisfaction and don't have any
configurability or make sense to plug into anything else. Making them
fully fledged SimObjects would be an awkward fit, and overkill since
there's a relatively simple alternative. In the case of x86 there really
wasn't any previous attempt to serialize, so at least some work was
necessary no matter what. I can see how it might not always be clear
when objects need to be serialized manually or automatically, though.

Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[nathan binkert]

> Did we ever write down what those changes were?  I recall that
> discussion but not the details, and a quick search of my email didn't
> turn anything up.

No.  I think I remember most of the details.  I'll try to throw
together a wiki page.

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[Steve Reinhardt]

On Wed, Aug 4, 2010 at 12:40 PM, nathan binkert  wrote:
>
> Perhaps we could figure out if we (or Joel :) could somewhat quickly
> implement some of the Serialization changes that we discussed.

Did we ever write down what those changes were?  I recall that
discussion but not the details, and a quick search of my email didn't
turn anything up.

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[nathan binkert]

> We do have the Serializable class and could track all the instances of
> that.  One question is whether there's enough overhead in SimObjects
> that we really need a lighter-weight class to support these cases.

Well, SimObjects have a Python component and must be described in at
least two files.  I think there's a fair amount of extra overhead.
One thing though is that there are certain objects like the
EthPacketData that we wouldn't want to have to get onto and off of the
global serialization list and will still want to serialize manually.
I personally would rather not make things SimObjects that nobody will
ever mess with.  Alternatively, we could differentiate a Python
exposed SimObject from a C++ only SimObject. and fold Serializable
into the latter.

Perhaps we could figure out if we (or Joel :) could somewhat quickly
implement some of the Serialization changes that we discussed.

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[Steve Reinhardt]

On Wed, Aug 4, 2010 at 8:43 AM, nathan binkert  wrote:
>> So should we be converting these subobjects to SimObjects to make it
>> easier to serialize them?  Joel previously ran into a bug with the
>> timer object (the MC one) where the Tsunami code was properly
>> calling its serialize/unserialize functions but the x86 wasn't, which
>> would have been avoided if the timer had been a SimObject.
>
> Perhaps better would be to make the serialization of objects use a
> separate list from the list of SimObjects.  Currently, we have this
> lame Globals object that is serializable (and is explicitly listed in
> Serializable::serializeAll().  If we did that, then we could make any
> object serializable without worrying about whether it is a SimObject.
> The only requirement is that the object must have a name().

We do have the Serializable class and could track all the instances of
that.  One question is whether there's enough overhead in SimObjects
that we really need a lighter-weight class to support these cases.

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[nathan binkert]

> So should we be converting these subobjects to SimObjects to make it
> easier to serialize them?  Joel previously ran into a bug with the
> timer object (the MC one) where the Tsunami code was properly
> calling its serialize/unserialize functions but the x86 wasn't, which
> would have been avoided if the timer had been a SimObject.

Perhaps better would be to make the serialization of objects use a
separate list from the list of SimObjects.  Currently, we have this
lame Globals object that is serializable (and is explicitly listed in
Serializable::serializeAll().  If we did that, then we could make any
object serializable without worrying about whether it is a SimObject.
The only requirement is that the object must have a name().

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[Steve Reinhardt]

On Tue, Aug 3, 2010 at 10:43 PM, nathan binkert  wrote:
>> No, I don't think those should be SimObjects since they're really just
>> handy abstractions for use internal to the I8042 (PS/2 keyboard and
>> mouse controller). It would be reasonable, though, to still put
>> serialization methods on them the I8042 could call so they manage their
>> own data. The Channel structs of the IDE controller work like that I think.
>
> Unfortunately, serializing sub objects is a pain in the butt.  Look at
> how it is done in the various ethernet objects (like PacketFifo and
> EtherPacket, etc.)

So should we be converting these subobjects to SimObjects to make it
easier to serialize them?  Joel previously ran into a bug with the
timer object (the MC one) where the Tsunami code was properly
calling its serialize/unserialize functions but the x86 wasn't, which
would have been avoided if the timer had been a SimObject.

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[nathan binkert]

> No, I don't think those should be SimObjects since they're really just
> handy abstractions for use internal to the I8042 (PS/2 keyboard and
> mouse controller). It would be reasonable, though, to still put
> serialization methods on them the I8042 could call so they manage their
> own data. The Channel structs of the IDE controller work like that I think.

Unfortunately, serializing sub objects is a pain in the butt.  Look at
how it is done in the various ethernet objects (like PacketFifo and
EtherPacket, etc.)

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Checkpointing x86

[Gabe Black]

No, I don't think those should be SimObjects since they're really just
handy abstractions for use internal to the I8042 (PS/2 keyboard and
mouse controller). It would be reasonable, though, to still put
serialization methods on them the I8042 could call so they manage their
own data. The Channel structs of the IDE controller work like that I think.

Gabe

Joel Hestness wrote:
> Hi,
>   This question is probably for Gabe:
>   I'm currently implementing checkpointing for x86, and I have run
> into a question about inheritance with a couple x86-specific devices.
>  src/dev/x86/i8042.hh defines a PS2Device, which doesn't inherit from
> anything, but it looks like the PS2Keyboard and PS2Mouse have state
> that might need to be checkpointed (e.g. mouse status in the case that
> Linux enables/disables it).
>   Should PS2Device descend from SimObject?  (if so, through a
> particular subclass of SimObject?)
>   Thanks,
>   Joel
>
>
> -- 
>   Joel Hestness
>   PhD Student, Computer Architecture
>   Dept. of Computer Science, University of Texas - Austin
>   http://www.cs.utexas.edu/~hestness
> 
> 
>
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>   

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] Checkpointing x86

[Joel Hestness]

Hi,
  This question is probably for Gabe:
  I'm currently implementing checkpointing for x86, and I have run into a
question about inheritance with a couple x86-specific devices.
 src/dev/x86/i8042.hh defines a PS2Device, which doesn't inherit from
anything, but it looks like the PS2Keyboard and PS2Mouse have state that
might need to be checkpointed (e.g. mouse status in the case that Linux
enables/disables it).
  Should PS2Device descend from SimObject?  (if so, through a particular
subclass of SimObject?)
  Thanks,
  Joel


-- 
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.edu/~hestness
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev