Yea, it makes sense to do that now where perhaps it did not before. Another
approach that you may or may not like better would be to activate the
context (which should take you from Halted to Active) but then immediately
suspend it.
Steve
On Fri, Apr 17, 2009 at 10:40 PM, Gabe Black wrote:
> J
Just to make sure I'm interpreting this correctly, I should be able to
suspend a halted CPU to go directly to suspended, correct? The simple
CPU asserts in that case. The attached patch fixes it, but I want to
make sure I'm not getting the status stuff turned around again.
Gabe
Lisa Hsu wrote:
>
No, we don't support that. O3 is too complicated, has too much state to
checkpoint, so we only checkpoint and restore AtomicCPU, then move into the
desired CPU model post-checkpoint.
On Fri, Apr 17, 2009 at 7:26 PM, Gabriel Michael Black <
gbl...@eecs.umich.edu> wrote:
> Quoting Steve Reinhardt
> But you could checkpoint O3 and then restore directly, couldn't you?
No, we currently don't support that. We also don't support
checkpointing the caches.
Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
Quoting Steve Reinhardt :
> On Fri, Apr 17, 2009 at 1:43 PM, Gabriel Michael Black <
> gbl...@eecs.umich.edu> wrote:
>
>>
>> You should also be sure to test starting from a checkpoint which I
>> believe is different from a switchover, although I'm not sure.
>
>
> It shouldn't be different from O3'
On Fri, Apr 17, 2009 at 1:43 PM, Gabriel Michael Black <
gbl...@eecs.umich.edu> wrote:
>
> You should also be sure to test starting from a checkpoint which I
> believe is different from a switchover, although I'm not sure.
It shouldn't be different from O3's perspective; we always restore from a
Quoting Steve Reinhardt :
> On Fri, Apr 17, 2009 at 1:37 PM, nathan binkert wrote:
>
>> >> I'm not an expert on this code, but I think it's preventing excessively
>> >> restarting the CPU if you do a switchover or resume from a checkpoint.
>> >
>> > Yea, that's exactly my assumption too, but I'd
On Fri, Apr 17, 2009 at 1:37 PM, nathan binkert wrote:
> >> I'm not an expert on this code, but I think it's preventing excessively
> >> restarting the CPU if you do a switchover or resume from a checkpoint.
> >
> > Yea, that's exactly my assumption too, but I'd feel much better if
> someone
> >
>> I'm not an expert on this code, but I think it's preventing excessively
>> restarting the CPU if you do a switchover or resume from a checkpoint.
>
> Yea, that's exactly my assumption too, but I'd feel much better if someone
> could explain in detail why it's necessary rather than just leaving i
On Fri, Apr 17, 2009 at 9:42 AM, Gabe Black wrote:
> > So the idea is that we only call initCPU() if the thread is in the
> > Suspended state (I believe there's a more straightforward way to code
> > that!), which the comment implies is because we only want to call
> > initCPU() when the thread
Steve Reinhardt wrote:
> I can see where this patch solves the immediate problem, but it's not
> clear it's not just a band-aid. The real question is what is the code
> supposed to be doing?
>
> The larger context in FullO3CPU::init() is this:
>
> for (int tid=0; tid < number_of_threads; tid++
I can see where this patch solves the immediate problem, but it's not clear
it's not just a band-aid. The real question is what is the code supposed to
be doing?
The larger context in FullO3CPU::init() is this:
for (int tid=0; tid < number_of_threads; tid++) {
#if FULL_SYSTEM
ThreadC
The patch below seems to fix it. I think there may be a similar issue
with the in order model. There's a bug in the wakeup function of I
believe all the CPU models where it only wakes up from Suspended and
just returns if you're Halted. I have a patch in my queue that fixes it
for the simple CPU, b
First some info that might be useful. When I stopped my second run it
spit out statistics and I noticed that no instructions actually
committed. I tried running with Exec and got the following forever which
starts immediately and is easy to see.
145886000: system.cpu T0 : @arch/alpha/kernel/head.S
I'm taking a look at this now... I suspect it may be related to my recent
thread status changes.
Steve
On Thu, Apr 16, 2009 at 9:27 PM, Steve Reinhardt wrote:
> Those tests passed on April 5 and took 395 and 440 seconds on zizzer,
> respectively. So (1) they must have broken since then and (2)
Those tests passed on April 5 and took 395 and 440 seconds on zizzer,
respectively. So (1) they must have broken since then and (2) if they're
taking longer than 10 minutes or so (depending on where you're running them)
they're definitely broken.
Steve
On Thu, Apr 16, 2009 at 9:08 PM, Gabe Black
All the regressions passed with my changes applied except for tsunami-o3
and tsunami-o3-dual. Those had run for 15 hours and not finished when I
checked on them which is obviously way to long. I removed my patches and
tried it on the head, but it's been running there for an hour and still
hasn't fi
I think we need some code that walks the hierarchy below each system
and pulls out the details of the system. This includes CPUs (that are
going to boot not that are all in the hierarchy), their speed, perhaps
cache configuration details, PCI devices, etc. Then there can be a
platform speci
Quoting Korey Sewell :
> Gabe, briefly can you talk about what you're big push is going to be on?
It's almost all stuff to get an SMP kernel to boot in x86. There are a
couple patches that affect things outside of x86, but I think those
are limited to the simple CPU.
>
> I'm really scramblin
Gabe, briefly can you talk about what you're big push is going to be on?
I'm really scrambling to get these MIPS fixes in for O3 since a major
culprit of it getting continually broken is the lack of a regression
test. People (including me) can change stuff and unknowingly break
MIPS code. Then, I
I'm going to be pushing a lot of stuff soon, so please hold off on
pushing into the repository until that happens. I'm going to almost
empty my queue, but there's a hack in there to set up the Intel MP table
and maybe one or two other spots so that it has the right information
for more than one CPU
21 matches
Mail list logo
