Re: [2.4.17/18pre] VM and swap - it's really unusable

On Sat, Jan 12, 2002 at 01:01:39AM -0500, Robert Love wrote:
> could even be merged.  Daniel Phillips suggested a passive tool on IRC. 
> Preempt-stats works like this.  It is off-by-default and, when enabled,
> measures time between lock and unlock, reporting the top 20 worst-cases.

I think one of the problems with this entire debate is lack of meaningful
numbers. Not for the first time, I propose that you test with something
that tests application benefits instead of internal numbers that may not
mean anything. For example, there is a simple test
		/* user code */
		get time.
		count = 200*3600; /* one hour */
		while(count--){
			read cycle timer
			clock_nanosleep(5 milliseconds)
			read cycle timer
			compute actual delay and difference from 5 milliseconds
			store the worst case
			}
		get time.
		printf("After one hour the worst deviation is %d clock ticks\n",worst);
		printf("This was supposed to take one hour and it took %d", compute_elapsed());

		

> 
> Begin working on the worst-case locks.  Solutions like Andrew's
> low-latency and my lock-break are a start.  Better (at least in general)
> solutions are to analyze the locks.  Localize them; make them finer
> grained.  Analyze the algorithms.  Find the big problems.  Anyone look

The theory that "fine grained = better" is not proved. It's obvious that
"fine grained = more time spent in the overhead of locking and unlocking locks and
		potentially more time spent in lock contention
		and lots more opportunities of cache ping-pong in real smp
		and much harder to debug"
But the performance gain that is supposed to balance that is often elusive.

> at the tty layer lately?  Ugh.  Using the preemptive kernel as a base
> and the analysis of the locks as a list of culprits, clean this cruft
> up.  This would benefit SMP, too.  Perhaps a better locking construct is
> useful.
> 
> The immediate result is good; the future is better.

Removing synchronization by removing contention 
is better engineering than fiddling about with synchronization
primitives, but it is much harder.

-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com