[Lse-tech] Minutes from 11/30 Call

[Hanna L. <ha...@us...>]

Minutes from LSE Tech Conference Call 11/30


		Michael Jennings - Large Systems Foundry
		mi...@tu...

Started from the Atlas project which take 
advantage of mckinnly processor. 

Atlas entails 8 major enhancements:

mckinnly, acpi, static domain partitioning, machine check handling,
ccnuma, hotplug suport, dynamic domain partitioning, discontiguous memory

The project started about a year ago.

Recently moved projects to SourceForge. 

The name is now Linux on Large Systems
combined 6 new projecdts with 4 existing ones.

There is an email list with about 40 people
and weekly engineering calls every Thursday at 9:30am

Here are the links to the foundry and other info:

Linux on Large Systems Foundry
http://foundries.sourceforge.net/large/

Linux on Large Systems Mailing List
http://lists.sourceforge.net/lists/listinfo/large-discuss

 -ACPI for Large Systems https://sourceforge.net/projects/acpi-largesys/
 -IA64 Linux MCA recovery https://sourceforge.net/projects/mca-recovery/
 -Discontiguous Memory https://sourceforge.net/projects/discontig/
 -Static Domain Partitioning https://sourceforge.net/projects/sdpart/
 -ccNUMA https://sourceforge.net/projects/lse/
 -Hot Plug Memory https://sourceforge.net/projects/lhms/
 -Hot Plug Processor https://sourceforge.net/projects/lhcs/
 -Hot Plug I/O Node https://sourceforge.net/projects/linux-hotplug/ &
  https://sourceforge.net/projects/pcihpd/


		Ray Bryant - Lockmeter Changes

Current implementation of rwlocks is mostly broken.
Causing a notice at the top of output.
In order to make unlock handling efficient it currently
caches location of statistics lock inside of lock
being measured. Which works fine for spinlocks but for 
rwlocks held in read mode potentially need one of these 
hints for every process in the system. No good place to 
put all that info.

There are a number of single use rw locks
in the kernel. Take a lot of space to allocate them all
in the rw table,  eventually run out of space because
we don't know when to free the info.

Ray has a fix for this. The code is complete and 
tested but it needs some cleanup. However, the data
structures and lockstat program need work. It is 
complicated and will take a few weeks of work.
Anyone volunteering?

Another option is to make locks bigger it would
mean lockstat wouldnt need another datastructure. 
But the original design specified we werent going to 
change the size of the lock. 

Paul McKenney- You don't have a map from virtual address
to lock. If you did have a mapping from virtual addresses
to locks then when memory is freed could free all
locks in that range. 

There are many ways to skin a cat.

Ray- I was really hoping to find out- do people care
about rw locks?

Paul- Here are two other approaches that are more simple
but could be tried: 

1) keep track only of the write side contention level.
	The problem with this is if the read is heavily the 
	write time could be low and you wouldnt see the contention.
	This is similar to what we did in Dynix/PTX, has low overhead.

2) use a counter to keep track of fraction that somebody holds
	lock for read.

Ray- lockstat is set up on a per caller basis. there isnt
really a counter per lock, but a counter per caller of lock.

Paul- there is a place for both having all the info and
having only most the info.