There is also a gettid system call, so you can look for that and see how it gets the tid.
Nate On Wed, May 26, 2010 at 1:08 PM, Ali Saidi <[email protected]> wrote: > There is some way. I don't know how to get the tid, but you should be able to > get a unique value for them by checking the kernel stack pointer base. It > will be set in alpha_switch_to right after the call_pal PAL_swctx, and is > generically available in r8 while in the kernel (It's calculated by ~0x3ffff > & $sp). The unique value (actually called this) in the pal process control > block (pcb) should also be unique. It's 0x20 from the start of the PCB, which > is also 0x20 from the start of the kernel stack pointer which the code you're > messing with is accessing. > > Ali > > > On May 25, 2010, at 11:01 PM, ef wrote: > >> I went ahead and messed with the patched m5 kernel, and took a look into >> struct taskinfo as well as threadinfo, I cant seem to find a unique thread >> ID anywhere. I am not sure if this is possible, any ideas? >> >> >> On Tue, May 25, 2010 at 5:59 PM, ef <[email protected]> wrote: >> After doing some digging around it seems that it is working, however the PID >> is unable to distinguish between multiple threads since they all give the >> same value. What I want is the thread id. Do you think it is possible to get >> this info in M5? >> >> I was looking through the kernel and have no idea what Im doing. >> >> Thanks >> >> >> >> >> >> On Mon, May 24, 2010 at 10:43 PM, Ali Saidi <[email protected]> wrote: >> I don't think there is, but it's been unused for a while, so there could be >> some issues. Let us know what you find out. >> >> Thanks, >> Ali >> >> On May 24, 2010, at 9:03 PM, ef wrote: >> >> > Is there a bug in it? It is able to distinguish between different >> > processes like Benchmark, RCS etc.. but every PID is the same. Im going to >> > take a look into it. >> > >> > Thanks, >> > EF >> > >> > On Sun, May 23, 2010 at 8:32 PM, Ali Saidi <[email protected]> wrote: >> > If you look at src/arch/alpha/linux/system.cc there in a class called >> > PrintThreadInfo. This pretty much does what you want assuming you're using >> > our kernel or a kernel built from our patch queue. M5 sets an event on the >> > kernel alpha_switch_to function and when that is executed it uses the >> > kernel stack to figure out what the running process/tid is. You'll need to >> > remove the false from the if statement that creates the event around line >> > 139 for this to work. >> > >> > Ali >> > >> > >> > >> > On May 22, 2010, at 5:14 PM, ef wrote: >> > >> > > Any additional advice on being able to this is appreciated. Basically I >> > > want to have M5 be able to distinguish between threads not CPU. Since in >> > > PARSEC benchmarks, threads tend to move around between CPUs. >> > > >> > > On Sat, May 22, 2010 at 9:57 AM, Steve Reinhardt <[email protected]> >> > > wrote: >> > > There's nothing built-in for this that I know of. The issue is that >> > > you're trying to detect an OS event... you could hook some action that >> > > the OS takes only when scheduling a new thread, like perhaps updating >> > > the page table base pointer or writing to the uniq register (via the >> > > wruniq instruction). Someone like Nate or Ali who's done more >> > > hands-on low-level Alpha Linux work could provide better details I'm >> > > sure. >> > > >> > > Steve >> > > >> > > On Tue, May 18, 2010 at 9:15 PM, ef <[email protected]> wrote: >> > > > Hello, >> > > > >> > > > I was wondering if there is a way for m5 (not glibc or the kernel) to >> > > > signal >> > > > when a new thread is on a cpu. I have some benchmarks that create new >> > > > threads in the middle of execution, and I would like to see output on >> > > > them >> > > > being pinned to processors (I have more threads than processors, FS >> > > > MODE). I >> > > > looked through and tested trace flags and I couldnt find anything. Is >> > > > there >> > > > such flag? >> > > > >> > > > If not anyone know where I should implement a DPRINTF in m5 to do this? >> > > > >> > > > Thanks, >> > > > EF >> > > > >> > > > _______________________________________________ >> > > > 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 >> > >> > _______________________________________________ >> > 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 > > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
