Hi all,
I am working with a couple researchers at North Carolina State University looking at the TLB behavior. Past studies in this area have used statically linked programs like SPEC CPU to provide workload for the simulator. This is very different than the typical shared-library, GUI application available on the desktop. We would like to have a sampling of workload programs that are more like the typical programs that people use on desktop machines. The characteristics we are looking for in the examples are:
-represent commonly-performed tasks, e.g. edit file and view document -depend on a number of dynamically-linked libraries -use GUI -have built-in accessibility features needed to automate the experiment with dogtail -run for a couple seconds, so instrumented version doesn't take too long -doesn't require network access
Currently, we have some example workloads using gthumb, evince, and abiword. They are driven by dogtail. We are looking for some additional examples to round out the experiments. Some GUI tests might be suitable for this, but would like to have examples that are more like normal person might use the software rather than a minimal test cases.
-Will
On 05/15/2007 10:28 PM, William Cohen wrote:
Hi all,
I am working with a couple researchers at North Carolina State University looking at the TLB behavior. Past studies in this area have used statically linked programs like SPEC CPU to provide workload for the simulator. This is very different than the typical shared-library, GUI application available on the desktop. We would like to have a sampling of workload programs that are more like the typical programs that people use on desktop machines. The characteristics we are looking for in the examples are:
-represent commonly-performed tasks, e.g. edit file and view document -depend on a number of dynamically-linked libraries -use GUI -have built-in accessibility features needed to automate the experiment with dogtail -run for a couple seconds, so instrumented version doesn't take too long -doesn't require network access
Currently, we have some example workloads using gthumb, evince, and abiword. They are driven by dogtail. We are looking for some additional examples to round out the experiments. Some GUI tests might be suitable for this, but would like to have examples that are more like normal person might use the software rather than a minimal test cases.
-Will
my colleagues are very fond of nedit
On 5/15/07, William Cohen wcohen@redhat.com wrote:
The characteristics we are looking for in the examples are:
-represent commonly-performed tasks, e.g. edit file and view document -depend on a number of dynamically-linked libraries -use GUI -have built-in accessibility features needed to automate the experiment with dogtail -run for a couple seconds, so instrumented version doesn't take too long -doesn't require network access
Have you looked at the mugshot compiled stats for most commonly used applications for registered mugshot users who are running fedora? http://mugshot.org/applications I think gedit and evince are obvious candidates, but pretty much all the gtk based applications that are highly ranked should work for you.
-jef
Jeff Spaleta wrote:
On 5/15/07, William Cohen wcohen@redhat.com wrote:
The characteristics we are looking for in the examples are:
-represent commonly-performed tasks, e.g. edit file and view document -depend on a number of dynamically-linked libraries -use GUI -have built-in accessibility features needed to automate the experiment with dogtail -run for a couple seconds, so instrumented version doesn't take too long -doesn't require network access
Have you looked at the mugshot compiled stats for most commonly used applications for registered mugshot users who are running fedora? http://mugshot.org/applications I think gedit and evince are obvious candidates, but pretty much all the gtk based applications that are highly ranked should work for you.
-jef
Jef,
Thanks for the suggestion.
We already have an evince example. Have abiword as a word processor example, but the gedit might be good also.
-Will
On Tue, May 15, 2007 at 03:28:15PM -0400, William Cohen wrote:
linked programs like SPEC CPU to provide workload for the simulator. This is very different than the typical shared-library, GUI application
You know you can catch TLB misses on some real x86 processors I assume ?
(You load the page table entry as missing then when you take the trap you put the entry in, touch the page to load it, and then mark it missing again)
Alan
Alan Cox wrote:
On Tue, May 15, 2007 at 03:28:15PM -0400, William Cohen wrote:
linked programs like SPEC CPU to provide workload for the simulator. This is very different than the typical shared-library, GUI application
You know you can catch TLB misses on some real x86 processors I assume ?
(You load the page table entry as missing then when you take the trap you put the entry in, touch the page to load it, and then mark it missing again)
Alan
Hi Alan,
The use of the page table traps might be faster than the valgrind simulator. It also might simplify some of the analysis; valgrind has a lot of additional pages for the binary translation. However, the valgrind simulator does everything in user space and avoid needing root access on the machine.
-Will
On Tue, May 15, 2007 at 10:50:03PM -0400, William Cohen wrote:
The use of the page table traps might be faster than the valgrind simulator. It also might simplify some of the analysis; valgrind has a lot
Its a lot faster and if you keep the trap handler in a 4MB page its fairly close to accurate in its results as the 4MB and standard TLB isn't generally shared
of additional pages for the binary translation. However, the valgrind simulator does everything in user space and avoid needing root access on the machine.
And finding a PC for the experiment that you can wipe and use is hard ? Oh wait this is a university perhaps thats true
Alan Cox wrote:
On Tue, May 15, 2007 at 03:28:15PM -0400, William Cohen wrote:
linked programs like SPEC CPU to provide workload for the simulator. This is very different than the typical shared-library, GUI application
You know you can catch TLB misses on some real x86 processors I assume ?
(You load the page table entry as missing then when you take the trap you put the entry in, touch the page to load it, and then mark it missing again)
Alan
Hi Alan,
This method would address some of the for future work: how to speed up the data collection and avoid the distortions caused by the addition mmap regions valgrind pulls in.
I think that there have been some previous research implementing this, e.g. Tape Worm. Just thinking how this TLB trap handling would work for the following cases:
instructions spanning pages instructions with data reference (two (or more) page accesses)
The ability not to need a dedicated machine did factor into the choice. The use of Valgrind was also influence about what students are comfortable with. Modifying valgrind, a user-space only tool, is a bit easier when things don't work correctly for a student.
-Will