Korey's description applies to the initial thread that gets set up for
each process (application), but for the additional threads that are
created for multithreaded processes, all M5 does is allocate empty
memory and it's up to the user library to initialize it.
This stack space is never freed. The current implementation was written
only to support SPLASH-type benchmarks which allocate N threads up
front, at most one thread per processor, and then leave those threads
running for the duration of the program. M5 doesn't even track which
thread is using which stack; it only uses a single per-process variable
(process->next_thread_stack_base) to figure out the next open sport in
the address space to place another stack if requested.
If you want to do something more dynamic, you have two main choices, I
think:
1. Add code to M5 to track the per-thread stacks and add a function that
gets called when a thread is destroyed, unmaps the virtual addresses,
and puts both the physical memory and the virtual address space back on
free lists to be reused on another thread create call.
2. Leave M5 as it is (allocating one thread per processor) and have your
user-level code (running as part of the simulated program) reassign the
M5 threads and stacks to various "user-level" threads as you create and
destroy them.
This choice is analogous to doing kernel-level vs. user-level threads in
a real system... which one is better depends on what you're trying to model.
Steve
Korey Sewell wrote:
HI Jiayuan,
I dont see a place where stack_createFunc gets called specifically in
M5 code so I'm assuming it must be called by whatever software your
running on M5.
However, since you're running multithreaded SE mode (on different CPUs
right?), then a good point of reference is the "argsInit" function in
the src/sim/process.cc file.
For Syscall Emulation, each process is given a "LiveProcess" object
and that function initializes the arguments to that process and also
sets up the initial stack for that process.
You'll also notice that the architecture specific Process objects
(e.g. AlphaTru64LiveProcess found in arch/alpha/tru64/process.hh)
derive from the LiveProcess object too.
Since other people might be interested in this question, I went ahead
and posted the answer on the M5 FAQ page:
http://www.m5sim.org/wiki/index.php/Frequently_Asked_Questions#Where_does_the_stack_and_program_arguments_get_setup_for_a_process_in_Syscall_Emulation_mode.3F
On 5/25/07, Jiayuan <[EMAIL PROTECTED]> wrote:
Thanks Steve!
By the way, as you said, in the multithreaded SE mode, each thread is
allocated a stack space in the physical memory. Will this space be
deallocated and reused when this thread terminates? I found in
tru64.hh that
stack_createFunc creates a 8M stack, but I haven't found where the
stack is
deallocated.
Thanks!
Jiayuan
Jiayuan wrote:
> Hey all,
>
>
>
> When I am trying to test the scalability of M5, I ran the splash2 FFT
> benchmark with 16 cores. M5 will prints out
>
>
>
> fatal: Out of memory, please increase size of physical memory.
>
>
>
> and then stop the simulation. I don't know how this could happen since
> obviously FFT is not that data intensive.
>
> My questions are:
>
> 1. Do you have any clue about what happened?
> 2. in SE mode, does M5 support page swapping? If I have a 128M
> physical memory and I am running 16 threads, each of them
allocate
> more than 8M memory space in the process's VIRTUAL address space,
> how does M5 handle this situation in SE mode?
You've pretty much answered your own question there... since there's no
OS in SE mode, there's no paging, so if your program tries to allocate
more space than the physical memory you've allocated it gives you the
error message you see above. Even if the FFT program itself doesn't
allocate that much, the system does allocate a certain amount of memory
per thread for stack space (I don't recall how much... it could be 8MB).
That's why you may run out as you increase the number of threads even
without changing the program.
Fortunately it should be easy to fix; as the message says, just increase
the physical memory size parameter in the configuration file.
Steve
>
>
>
> Thanks!
>
>
>
> Jiayuan
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
