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
