Date: | Thu, 6 Aug 2009 19:35:54 -0500 |
---|---|
From: | Dan Gibson <degibson@xxxxxxxx> |
Subject: | Re: [Gems-users] Thread migration in Gems |
Hi Jianghao, 1) Please don't reply directly to gems-users participants unless they ask you to do so -- I'm directing this thread back to gems-users so others can benefit from it. 2) Don't think about thread migration 'in GEMS'. Think about it on a real machine -- thats what we're simulating, after all. What causes thread migration? Well, random happenstance does. Another thing that causes it is when a thread tries to bind to a processor on which it is not currently running (of course, this assumes the OS respects thread binding...which I have never confirmed). So, since your target is look into sched_setaffinity(). Modify your application binary to fork a thread and call it. Regards, Dan On Thu, Aug 6, 2009 at 7:30 PM, Jianghao Guo <guojh.uc@xxxxxxxxx> wrote:
-- http://www.cs.wisc.edu/~gibson [esc]:wq! |
[← Prev in Thread] | Current Thread | [Next in Thread→] |
---|---|---|
|
Previous by Date: | Re: [Gems-users] Thread migration in Gems, Dan Gibson |
---|---|
Next by Date: | [Gems-users] benchmark workloads running on LogTM-SE, ruzhu kao |
Previous by Thread: | Re: [Gems-users] Thread migration in Gems, Dan Gibson |
Next by Thread: | [Gems-users] Using "Opal0.sim-step 4_000_0000_0000" command does not advance the simulation state, Wael Kdouh |
Indexes: | [Date] [Thread] |