On Fri, Jun 30, 2000 at 06:11:01PM +0200, Paolo Mantegazza wrote:
> The above is agreed totally. For me the two solutions are conceptually
> the same. In fact the practicall loss of performance on lesser machine
> can be proved to be marginal on the base of experience. To be precise I
I see some numbers with lmbench that worry me -- not too much, but
1% here, 1% there and pretty soon you have NT.
> In any case you must admit that it was not so when you rejected my
> proposal on March 1999. In any case if any marginal performance loss
> exists between the two solutions it is just on Linux, real time is not
> suffering in any case.
I went back and looked at the discussion and can't see what bothers you
so much. Probably I'm just insensitive.
> > BTW: Paolo and anyone else out there. There has for a long time
> > been an invitation to send complaints if you feel slighted in the CREDITS
> > file that is part of the RTLinux distribution. Send
> > me a list of what you believe
> > your contributions to be and, unless it is totally absurd, I'd be happy
> > to put it in the distribution.
>
> I do not ask for any credit, just admit it was not saw 1.5 years ago.
> After all we are discussing things that a lot of Computer Science
> graduates can do quite easily for free, just if it payed a meaningfull
> grade increase for their thesis.
>
> My proposal is the same as for March 1999( see:
I have the same reaction: yes, function pointers are convenient at times,
no I don't see how this should be a design paradigm. So if you want
a public acknowledgment that Paolo Mantegazza released code
implementing the RTLinux method using function pointers before we did,
I have always been happy to make such an acknowledgement. If you want me
to agree that this is the critical step for a "hardware abstraction",
I still disagree.
> > For those who want to know. Linus notes that in the x86,
> > cli/sti/pushfl/popfl are 8 bit instructions. Replacing these
> > with a "move mem,reg, call reg" inflates code and may cause cache
> > misses -- cli becomes a 10 byte or so operation instead of 1. The core Linux
> > developers are obsessive about cache lines, for good reason, and
> > we do see a minor slowdown in Linux on some x86s when any form
> > of RTLinux indirection is added. This was not always the case, but
> > base Linux IRQ handling has improved.
>
> The problem is clearly not one of bytes but of cycles of excution. The
The problem is actually more a problem of bytes and cache misses.
> outcome depends on how many bytes of code the above are protecting. In
> any case RTL and RTAI are using them as such so, I repeat, it is just a
The cache miss won't come on the fetch of the cli_function, but from the
general expansion of code -- but let's not argue this since we both agree
it is usually not anything to worry about.
> problem of having Linux pay a marginal cost, not the hard real time
> applications running unde RTL/RTAI.
We pay the cost in cache misses, but see above.
>
> Ciao, Paolo.
--
---------------------------------------------------------
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
