Hi Veydan, Lisa, I'm sorry I forgot to mention this. I also don't know how to get software thread id from hardware legally. But I tried a hack which seems to work - I'm not sure if it will work correctly always - Sometimes I get weird thread ids with this method. If someone can fix it, it would be great.
I followed what was done in pthreads library code for alpha-linux: 0000000120000bd8 <__pthread_self>: 120000bd8: 9e 00 00 00 rduniq 120000bdc: a0 00 00 a4 ldq v0,160(v0) 120000be0: 01 80 fa 6b ret I'm not sure, though, what rduniq returns (Surely it is an address value in user space, and if we add 160 to it, we get the address of the location where thread id is stored). http://www.koders.com/noncode/fid0127B7742C33DC234D462F13D3CAD5800EF8F586.aspxhas the OSF implementation for rduniq (I guess it will be similar for linux). In m5 simulator (cpu/simple/timing.cc), I tried to get the thread id like this: #if FULL_SYSTEM /* WARNING: This will only work for ALPHA systems */ Addr uLUniqueID, uLUserSpaceAddr, uLSWTId; VirtualPort *vpP; FunctionalPort *ppP; /* Set up software thread id */ uLUniqueID = readMiscRegNoEffect(TheISA::IPR_PALtemp23); ppP = thread->getPhysPort(); assert(ppP); ppP->readBlob((Addr) (uLUniqueID + 0x20), (uint8_t*) &uLUserSpaceAddr, sizeof(Addr)); vpP = thread->getVirtPort(); assert(vpP); vpP->readBlob((Addr) (uLUserSpaceAddr + 160), (uint8_t*) &uLSWTId, sizeof(Addr)); if (uLSWTId > 0x1000000000000000LL) { uLSWTId = (unsigned long long) -1; } #endif For THIS to work, we need to link with -lpthreads. Thanks and Regards, Arun PS: This is a nice reference for Alpha Architecture: ftp.compaq.com/pub/products/alphaCPUdocs/alpha_arch_ref.pdf On Tue, Jun 9, 2009 at 7:51 AM, Lisa Hsu <[email protected]> wrote: > I don't think there's a way for you to know SOFTWARE thread ID, but you can > know hardware thread id with context_id. But if, for example, you context > switch out a software thread that runs on hardware context X, then the > hardware statistics for context X will be a combination of all the software > threads that ran on that hardware context. > I don't think you need to change the meaning of thread_id - just use > context_id or cpu_id, which in a non-SMT system are essentially the same > thing. > > Lisa > > On Mon, Jun 8, 2009 at 5:27 PM, Veydan Wu <[email protected]> wrote: > >> Hi, Arun, thanks for your suggestion. I have never try to use >> pthread_self before, but I want to get the thread ID from the hardware, I >> mean from M5, rather than from software. So what I am really looking for is >> a structure that can tell me which thread the executing instrution is belong >> to, of course this structure must inside M5. Thank you ! >> >> Veydan >> >> >> >>> Subject: Re: [m5-users] a simple question about thread ID >> >> >> Hi Veydan, >> Did you try linking with pthreads library explicitly? I had a problem >> finding out thread ids without linking explicitly with -lpthread. (I was >> getting 0's for pthread_self). After linking, I started getting thread >> id's >> like 0x4000, 0xc000, etc. Your programs will compile and link even if you >> don't do -lpthread. >> Best Regards, >> arun >> >> On Mon, Jun 8, 2009 at 6:07 AM, Veydan Wu <[email protected]> wrote: >> >> > >> > Hi, Lisa, thanks for your reply. I must run my programs on FS mode, each >> > thread must be associated to a core and there will not be multiple >> threads >> > on one core. Is that the only way to distinguish different >> threads(software >> > thread) is through cpu_id or context_id ? If I change the thread_id to >> be >> > one of the two ids, then I can distinguish different threads, is that >> right? >> > Thank you! >> > >> > Subject: Re: [m5-users] does M5 support SMT >> >> >> >> >> >> If you must do FS, then you can run a multi-threaded program on a CMP >> >> rather >> >> than an SMT platform. You can use the set_affinity syscall to attach a >> >> particular thread to a particular core. Search the archives, I'm sure >> it >> >> has been discussed before on the mailing list. >> >> Lisa >> >> >> >> On Wed, May 27, 2009 at 6:29 PM, Veydan Wu <[email protected]> wrote: >> >> >> >> > Thanks, Korey. But I must run my program on FS mode, some of my >> >> testbenches >> >> > fail to run on SE mode. >> >> > >> >> > Maybe running a multi-thread program on a single cpu core is my only >> >> > choice, but how to dinstinguish them against each other? Do you have >> any >> >> > idea about that? I think M5 run only one thread on one cpu core at a >> >> time, >> >> > as all the thread ID are 0. >> >> >> >> Subject: Re: [m5-users] a simple question about thread ID >> >> >> >> Sorry for the big delay in replying to this, I was just cleaning out my >> >> inbox and noticed this question. >> >> What you want is a context_id. Theoretically, in an SMT system there >> are >> >> context_ids, which are unique across the system, and cpu_ids, which are >> >> unique to each core, and thread_ids, which are unique within a >> core. So, >> >> if >> >> you have a 2-core 2-way SMT platform, you'd have cpu_id 0, 1, >> context_ids >> >> 0, >> >> 1, 2, 3, and cpu 0 would have thread 0 and thread 1, and cpu 1 would >> also >> >> have thread 0 and thread 1. >> >> >> >> If you are running in FS, there is no SMT support so all thread id's >> will >> >> be >> >> 0. What you are looking for is context_id. >> >> >> >> Good luck, >> >> Lisa >> >> >> >> > >> >> > Hi all, I am running a multi-thread program on M5 under ALPHA-FS >> mode. >> >> When >> >> > I tried to get the thread ID, it always return 0, and I cannot >> >> distinguish >> >> > them between different threads. I tried to get the thread ID >> >> > throught the function in thread_state structure, which is supposed to >> >> return >> >> > the thread ID. >> >> > My test program is implemented by POSIX thread library. Should I use >> the >> >> > function in the thread_state structure to get the thread ID ? Is >> those >> >> > functions supposed to return different thread ID? Sorry for such >> silly >> >> > question, but it really confuses me. Thanks! >> >> >> >> >> _______________________________________________ >> 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
