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

[yodaiken@fsmlabs.com]

On Tue, Jan 22, 2002 at 03:10:42AM +0100, Daniel Phillips wrote:
> On January 22, 2002 12:56 am, yodaiken@fsmlabs.com wrote:
> > I have not seen that argued - certainly I have not argued it myself.
> > My argument is:
> > 	It makes the kernel _much_ more complex
> 
> The patch itself is simple, so this must be an extended interpretation of the 
> word 'complex'.

I'm at a loss here. You seem to be arguing that
there there is a relationship between the complexity of a patch
that changes the entire synchronization assumption of the
kernel and the complexity of the result. But that seems
unbelievable. Is there some component of your argument I've missed?

> 
> > 	It has known costs e.g. by making the lockless 
> > 		per-processor caching  more difficult if not impossible
> 
> Not at all, the lazy man's way of dealing with this is to disable preemption 
> around that code, an efficient operation.

Well, aside from how easy it will be to isolate all that information,
doesn't that defeat the purpose of the patch?  There is a big
difference in design between
	try to get fromverylightweight cache
		fallback to slow but fair and safe pool
and
	try to bound worst case times

In the first case we amortize worst case times by making average case
very low. This is a common design methodology in Linux kernel: semaphores
are the classic example.
So I'm sure that you can add any number of hacks to the kernel, but my
argument stands: per-processor caching is a common case optimization that
de-optimizes worst case. If the purpose of preemption is to reduce
latency, per-processor caching is at counter-purposes.


It's also worth pointing out that every use of cpu-specific information
is dangerous if preemption is extended to smp.
	x = smp_processor_id();
	//get preempted
	do_something(memslab[x]); // used to be safe since only current can
				// do this.

	
> > 	It seems to lead to a requirement for inheritance
> 
> I don't know about that.  From the (long) thread above, it looks like you 
> haven't successfully proved the assertion that -preempt introduces any new 
> inheritance requirement.

Oliver cited the trivial case. He was ignored.

> > 	It has no demonstrated benefits.
> 
> Demonstrated to who?  I have certainly demonstrated the benefits to myself, 
> and others have attested to doing the same.

I've heard similar arguments in favor of aromatherapy and Scientology.

What's amazing about all the arguments in favor of preemption is that we
don't see any published numbers of the obvious application: a periodic
SCHED_FIFO process. We've done these experiments and the results are
_dismal_. 
Even ignoring this, the repeated publication of numbers showing that
Andrew's patches get better results and the repeated statement by 
Andrew that the hard part of latency reduction
is _not_ solved by preemption alone
is continually met with repetitions of the same unsubstantiated chorus:
	But it is easier to maintain  



> As far as arguments go, your main points don't seem to be rooted in firm 
> ground at all.  On the other hand, the proponents of this patch have 
> compelling arguments: it makes Linux feel smoother, it makes certain tests 
> run faster, it doesn't slow anything down measurably, it's stable and so on.  
> I even explained why it does what it does.  I don't understand why you're so 
> vehemently opposed to this, especially as it's a config option.

What you proposed is a
claimed explanation of why a task that experienced regular unfixable
latencies of multiple milliseconds waiting for I/O would have additional
latencies possibly reduced by some unknown amount. You failed to make a
case that this is either something that actually happens or that it would
ever make any difference.

BTW: I've made no arguments that the patch should not be made an option.
I've argued that it is based on a very bad design premise. As for
whether it should be added to 2.5,  sold by other vendors, advertised on TV,
used when operating heavy machinery, or taken by pregnant women,
that's not up to me.


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