Re: [m5-dev] suspending unallocated context
It looks like Alpha turns on all the CPUs to start with where x86 only turns on the BP and brings up the APs with IPIs. I think SPARC is actually more similar, but it looks like I'm already doing what it's doing. I remember Ali fixed some of the SPARC SMP boot issues recently, but I looking at that it doesn't seem to address this sort of thing. Gabe Steve Reinhardt wrote: Recalling from some of the issues with getting O3 MT to work, I believe there's a general confusion and inconsistency with respect to the meanings of suspended, unallocated, and perhaps other states. It's possible (maybe even likely) that the code that does SE-mode MT apps like SPLASH has requirements that are inconsistent with FS mode. So there's no right answer short of figuring out how it ought to be and fixing the half of the code that assumes something different. Can you tell how it works in Alpha FS? Seems like x86 shouldn't be any different. Steve On Sat, Feb 28, 2009 at 12:48 PM, Gabe Black gbl...@eecs.umich.edu wrote: I'm trying to bring up SMP under x86 FS, and I'm not able to wake up any AP because the wakeup function gives up if the CPU isn't suspended. The CPUs I'm working with are actually unallocated, so nothing happens. I had startupCPU set up to suspend the APs as the came up, but that causes a problem with the simple CPUs which insist the thread is Running, and again it's Unallocated. How is this supposed to work? Do I have to activate and then suspend a context? Or did somebody just leave a possible option out of an assert someplace? Gabe ___ 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] suspending unallocated context
I'm going to go with the theory that the wake up function needs to wake up unallocated CPUs too. Gabe Gabe Black wrote: It looks like Alpha turns on all the CPUs to start with where x86 only turns on the BP and brings up the APs with IPIs. I think SPARC is actually more similar, but it looks like I'm already doing what it's doing. I remember Ali fixed some of the SPARC SMP boot issues recently, but I looking at that it doesn't seem to address this sort of thing. Gabe Steve Reinhardt wrote: Recalling from some of the issues with getting O3 MT to work, I believe there's a general confusion and inconsistency with respect to the meanings of suspended, unallocated, and perhaps other states. It's possible (maybe even likely) that the code that does SE-mode MT apps like SPLASH has requirements that are inconsistent with FS mode. So there's no right answer short of figuring out how it ought to be and fixing the half of the code that assumes something different. Can you tell how it works in Alpha FS? Seems like x86 shouldn't be any different. Steve On Sat, Feb 28, 2009 at 12:48 PM, Gabe Black gbl...@eecs.umich.edu wrote: I'm trying to bring up SMP under x86 FS, and I'm not able to wake up any AP because the wakeup function gives up if the CPU isn't suspended. The CPUs I'm working with are actually unallocated, so nothing happens. I had startupCPU set up to suspend the APs as the came up, but that causes a problem with the simple CPUs which insist the thread is Running, and again it's Unallocated. How is this supposed to work? Do I have to activate and then suspend a context? Or did somebody just leave a possible option out of an assert someplace? Gabe ___ 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 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
Re: [m5-dev] suspending unallocated context
I agree that this stuff is all messed up. There's threads and cpus each which have various states that don't necessarily work with each other. Some of the states have to do with indicating that a CPU has nothing to do at the moment so we don't need to schedule a tick, and some indicate the type of stuff that Gabe is discussing. Nate On Sat, Feb 28, 2009 at 1:08 PM, Steve Reinhardt ste...@gmail.com wrote: Recalling from some of the issues with getting O3 MT to work, I believe there's a general confusion and inconsistency with respect to the meanings of suspended, unallocated, and perhaps other states. It's possible (maybe even likely) that the code that does SE-mode MT apps like SPLASH has requirements that are inconsistent with FS mode. So there's no right answer short of figuring out how it ought to be and fixing the half of the code that assumes something different. Can you tell how it works in Alpha FS? Seems like x86 shouldn't be any different. Steve On Sat, Feb 28, 2009 at 12:48 PM, Gabe Black gbl...@eecs.umich.edu wrote: I'm trying to bring up SMP under x86 FS, and I'm not able to wake up any AP because the wakeup function gives up if the CPU isn't suspended. The CPUs I'm working with are actually unallocated, so nothing happens. I had startupCPU set up to suspend the APs as the came up, but that causes a problem with the simple CPUs which insist the thread is Running, and again it's Unallocated. How is this supposed to work? Do I have to activate and then suspend a context? Or did somebody just leave a possible option out of an assert someplace? Gabe ___ 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] suspending unallocated context
Nate, are you referring to the CPU's state vs. the actual thread-object's state? That connection between the two in my opinion has been ad-hoc for awhile or at least beyond my complete understanding. Changing things for FS breaks SE and vice-versa. Needless to say, we should probably get this straightened out and documented in the near future... On Sat, Feb 28, 2009 at 9:30 PM, nathan binkert n...@binkert.org wrote: I agree that this stuff is all messed up. There's threads and cpus each which have various states that don't necessarily work with each other. Some of the states have to do with indicating that a CPU has nothing to do at the moment so we don't need to schedule a tick, and some indicate the type of stuff that Gabe is discussing. Nate On Sat, Feb 28, 2009 at 1:08 PM, Steve Reinhardt ste...@gmail.com wrote: Recalling from some of the issues with getting O3 MT to work, I believe there's a general confusion and inconsistency with respect to the meanings of suspended, unallocated, and perhaps other states. It's possible (maybe even likely) that the code that does SE-mode MT apps like SPLASH has requirements that are inconsistent with FS mode. So there's no right answer short of figuring out how it ought to be and fixing the half of the code that assumes something different. Can you tell how it works in Alpha FS? Seems like x86 shouldn't be any different. Steve On Sat, Feb 28, 2009 at 12:48 PM, Gabe Black gbl...@eecs.umich.edu wrote: I'm trying to bring up SMP under x86 FS, and I'm not able to wake up any AP because the wakeup function gives up if the CPU isn't suspended. The CPUs I'm working with are actually unallocated, so nothing happens. I had startupCPU set up to suspend the APs as the came up, but that causes a problem with the simple CPUs which insist the thread is Running, and again it's Unallocated. How is this supposed to work? Do I have to activate and then suspend a context? Or did somebody just leave a possible option out of an assert someplace? Gabe ___ 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] suspending unallocated context
Yep. On Sat, Feb 28, 2009 at 6:40 PM, Korey Sewell ksew...@umich.edu wrote: Nate, are you referring to the CPU's state vs. the actual thread-object's state? That connection between the two in my opinion has been ad-hoc for awhile or at least beyond my complete understanding. Changing things for FS breaks SE and vice-versa. Needless to say, we should probably get this straightened out and documented in the near future... On Sat, Feb 28, 2009 at 9:30 PM, nathan binkert n...@binkert.org wrote: I agree that this stuff is all messed up. There's threads and cpus each which have various states that don't necessarily work with each other. Some of the states have to do with indicating that a CPU has nothing to do at the moment so we don't need to schedule a tick, and some indicate the type of stuff that Gabe is discussing. Nate On Sat, Feb 28, 2009 at 1:08 PM, Steve Reinhardt ste...@gmail.com wrote: Recalling from some of the issues with getting O3 MT to work, I believe there's a general confusion and inconsistency with respect to the meanings of suspended, unallocated, and perhaps other states. It's possible (maybe even likely) that the code that does SE-mode MT apps like SPLASH has requirements that are inconsistent with FS mode. So there's no right answer short of figuring out how it ought to be and fixing the half of the code that assumes something different. Can you tell how it works in Alpha FS? Seems like x86 shouldn't be any different. Steve On Sat, Feb 28, 2009 at 12:48 PM, Gabe Black gbl...@eecs.umich.edu wrote: I'm trying to bring up SMP under x86 FS, and I'm not able to wake up any AP because the wakeup function gives up if the CPU isn't suspended. The CPUs I'm working with are actually unallocated, so nothing happens. I had startupCPU set up to suspend the APs as the came up, but that causes a problem with the simple CPUs which insist the thread is Running, and again it's Unallocated. How is this supposed to work? Do I have to activate and then suspend a context? Or did somebody just leave a possible option out of an assert someplace? Gabe ___ 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 mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- -- Korey L Sewell Graduate Student - PhD Candidate Computer Science Engineering University of Michigan ___ 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
