• MatthewForgie

Matthew Forgie

Working with Gelato was fun, but now I've moved on.

Email: <mattf AT gelato DOT unsw DOT edu DOT au>

My ToDo list is at /ToDo.

The ToDo list is for my daily plans; I will also try to keep a /Diary of things I do and learn.

About me

I first started working at Gelato as a recipient of a Summer scholarship during the 2004/2005 Summer holidays. Currently, I am working as volunteer to extend the work that I did during the scholarship (creating visualisations for NUMA memory access patterns).

I am also in my final year of a combined undergraduate degree in electrical engineering and computer science.

Current plans

I will be working at Gelato for approximately 12hrs p/week (mostly Thursdays and Fridays) My plans are to:

• Create the bouncing bargraph visualisation (30hrs)
• Add GUI widgets and configuration to the visualisation (30hrs)
• Tweaking, debugging, etc. (24 hrs)

Summer Project

This was my plan for completing the Summer project:

Part A:

• Understand how NUMA architectures work and what information is available in the kernel and where.
  1. Search for NUMA resources
  2. Read through NUMA related code in the kernel
  3. Know the major sorts of NUMA architectures (e.g. fat-trees,hypercubes,NUMA-flex,torus,ring,etc.).
• Choose what sort of information would be useful to display for monitoring memory usage.
  1. Counters can be used to monitor accesses to particular ranges of memory addresses.
  2. A set of counters for each cpu, each counter monitoring a range of physical memory addresses.
  3. Counters can be incremented by the page fault handler (need to check if this is the right thing to watch).
• Find a way of passing this information to the user space.
  1. Sysfs will provide the means of passing information to userspace.
  2. PMUs will possibly provide the means of identifying which address caused the page fault
  3. SLIT and SRAT tables may provide other useful information to be exported.
  4. Information for building a concept of the physical layout needs to be found, so that the visualisation is representative of the physical layout of nodes.
  5. Store information as ASCII in a file in some defined format (so it can be read by the grahical app at later stage. This reduces the need for the graphical application to only use libraries that everybody already has installed(i.e. if someone doesn't want openGL, they could use a different front end.
  6. Try to confirm the right information is being measured.

Part B:

• Find an effective way of representing this information graphically. Must be scalable.
  1. Read PhD papers on visualisation methods for large node graphs.
  2. Compare various methods (advantages vs. disadvantages) with scalability in mind (~500 000 nodes)
  3. Derive requirements for what graphics tool needs to be able to do (as some tools may limit interaction with objects, for example).
• Investigate tools for building graphical applications, and choose one.
  1. Read about various graphics tools on the Wiki and Internet.
  2. Try writing simple programs to get a feel for which one will be best.
  3. Select tool which will be easiest to implement chosen graphical representation.
• Build GUI and various graphical objects for displaying information.
• Write code to take memory usage information and feed it into the GUI application.

Developing the GUI itself is of less importance than creating the backend program, and developing/specifying an effective means of visualising the information in a scalable way. Once this is done creating the GUI is trivial, and could be done in a number of different graphics tools/languages.

This will be subject to change.

CategoryHomepage