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

On Sun, Jan 13, 2002 at 04:33:44AM +0100, Roman Zippel wrote:
> Hi,
> 
> [e-mail] wrote:
> 
> > Well, how about a third possibility - that I see a problem you have not
> > seen and that you should try to argue on technical terms
> 
> I just don't see any problem that is really new. Alan's example is one
> of more extreme ones, but the only effect is that an operation can be
> delayed far more than usual, but not indefinitely.
> If you think preemption can cause a deadlock, maybe you could give me a
> hint, which of the conditions for a deadlock is changed by preemption?
> 
> > instead of psychoanlyzing
> > me or looking for financial motives?
> 
> If I had known, how easily people are offended by implying they could
> act out of financial interest, I hadn't made that comment. Sorry, but
> I'm just annoyed, how you attack any attempt to add realtime
> capabilities to the kernel, mostly with the argument that it sucks under
> IRIX. I people want to try it, let them. I prefer to see patches and if
> they should really suck, I would be first one to say so.

I'm annoyed that you take a comment in which I said that the Morton approach
was much preferrable to the preempt patch and respond by saying I "attack
any attempt to add realtime capabilities to the kernel". 
I'm all in favor of people trying all sorts of things. My original comment
was that the numbers I'd seen all favored the Morton patch and I still
haven't seen any evidence to the contrary.

I also made two very simple and specific comments:
	1) I don't see how processor specific caching, which seems
	essential for smp performance and will be more essential 
	with numa, works with this patch
	2) preempt seems to lead inescapably to priority inherit. If this
	is true, people better understand the ramifications now before they
	commit.

Of course, I think there are strong limits to what you can get for RT 
performance in the kernel - I think the RTLinux method is far superior.
Believe what you want - it won't change the numbers.

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