On Thu, Jul 22, 2010 at 10:03 AM, Korey Sewell <ksew...@umich.edu> wrote: > The problem is that there are some conventions that we would need to point > out and follow (i.e. Do threads start out Halted, Idle, or ???)
Yea, I know that's the key to the problems we had before, is that different people had different mental notions of what these states mean, which led to inconsistencies across the CPU models in terms of how they were/are handled. I agree that, ideally, the first step is to hash out some definitions so we can agree on what they should mean before we go changing the code again. Though if Ioannis wants to hack in some workarounds just to get his situation working he may want to do that rather than waiting on us to fix everything :-). But we would value his input in making sure that the long-term solution meets his needs as well as everyone else's. > and then > also sort out (at least for me) what is the true role and relationship > between ThreadContext and ThreadState. I always was confused by those two > and thought they should be merged into the same object Off the top of my head, the former is an interface while the latter is the canonical (but not necessarily only) implementation of that interface. But if it turns out that there's no foreseeable need for an alternative implementation then perhaps they should be merged. Or if my characterization is wrong please enlighten me. > I know at one point, > Steve was frustrated enough to just get things working and commit a change > for this stuff (maybe 1yr ago), Yup, I remember that too. > Lastly, there are some issues of how the architectural state gets > transferred in/out in SE mode since there is no explicit OS handler to do > this for you (e.g. assign a thread to a SMT hardware context in O3, before > there are enough physical registers ... or flushing the pipeline and > deallocating registers after a thread is suspended or halted) My general recollection is that a lot of the complexity came from trying to implement fancy SE-mode thread scheduling capabilities that never really worked and were never used. That's probably an overgeneralization of the situation, but to the extent that it's true, my reaction is that we should just scale back to the basics and get rid of any code that doesn't work. For example, just support some fixed number of hardware thread contexts without any dynamic adding or removing of contexts. (You will want to enable/disable or suspend/resume the ones that are there--are those different operations or the same thing?--but you never expand or reclaim the architectural state; I think that's one place where things got complicated and broken.) People who want serious thread scheduling should probably be using FS mode anyway, and people who really think they have a good reason to play with thread scheduling in SE mode probably want something very specific and so if the basic features aren't adequate then it's up to them to add in the features they need. Again, that's just my recollection/opinion, so speak up if you disagree. > If people want, I can try to summarize what changes I think need to be made > and then others with more knowledge on how that relates to things working > for FS_MODE can chime in as well. That would be awesome. I suggest starting a wiki page that tries to document how it ought to be, so that when we're done tweaking it we'll automatically have some documentation in place for future reference. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
