The first one sounds like a pretty reasonable thing to want to fix.
We might want to do something a little differently in case those
descriptors could be change for some other purpose. In that case we'd
want to make the reasonable side effect happen while not breaking M5's
output. For instance, if we supported fork, the stdin, stdout, stderr
descriptors might be used in order to hook a processes input and output
to something other than the terminal. I'm thinking this is safe to
ignore for the moment.
For the second one, I can see why you would want both. I think it
might be better to make exit kill the simulation normally but make
waiting for all threads an option. The going opinion was that you
normally wouldn't really have a situation where you'd let all of your
threads run out. You'd really have some other thread you're not
considering come in and run concurrently, so the trailing portion with
just a thread or two is less realistic. Personally, I won't loose any
sleep if this goes either way.
Gabe
Korey Sewell wrote:
Here are a couple things in my tree that I've edited and I believe
should be changes (in some form) in
the normal M5 tree:
UPDATE: I made the close() syscall in SE mode gives a warning and
ignores the call when the argument is between
0 and 2 (stdin, stdout, stderr).
WHY?: What happens in the spec2K sims I'm running on multiple CPUs is that
a workload finishes and uses the close() system call to close stdout
(close(1)). This has the effect of
suppressing not only the workloads output but M5's output. So, if you
are trying to debug something
after one workload finishes you'll see no debug output (since that is
redirected to stdout).
UPDATE: I made the exit() function in cpu/thread_context.hh checks to
see if other CPUs (and/or threads) are alive
before returning 1 and telling the simulation to exit. I had done
something similar for O3. (although it just does this
for the CPU so it probably doesnt work for non-SMT, multiprogrammed
workloads that want to run to completion)
WHY: I am running spec2k on two diff. SimpleCPUs simultaneously and my
sims are being cut off short (i.e. whenever
one thread calls exit()) when I really want the whole simulation to
finish. I believe the functionality where the sim.
stops as soon as one thread stops should probably be a simulation
option instead of a simulation assumption like
we have currently and the functionality where all threads run to
completion should be the default behavior.
Thoughts? Let me know if this makes sense and is "push-able" into the
tree.... Otherwise, I'll just happily keep
it to myself!
--
----------
Korey L Sewell
Graduate Student - PhD Candidate
Computer Science & Engineering
University of Michigan
------------------------------------------------------------------------
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
