Richard Gooch <rgooch@atnf.csiro.au> said:
: Well, thanks. This sounds more positive. However, I still think I
: should point out that a phrase like "encourage better thinking" is
: still not that tactful.
FLAME ON:
Oh, excuse me, Mr Gooch sir. I forgot that your brain is perfect and
that your code is perfect and that you have absolutely no room for
improvement whatsoever. How horribly rude of me to ever think that you
are less than perfect and that anything I could ever say or do could help
you in any way. Please accept my humble apologies, Mr Gooch sir, and rest
assured that I'll try and be more careful in the future.
FLAME OFF.
Sheesh.
: A few points here. Firstly, you said a number of times that "real" or
: "correct" applications don't have a large run queue.
And you've said yourself that you agreed with that, at least for RT
processes.
: Secondly, you have asserted that it won't be a problem for "realistic"
: applications which only have a few processes on the run queue. My
: tests on a Pentium 100 show that a mere 3 extra processes on the run
: queue doubles the scheduling/wakeup latency of an RT processes.
Whoop dee do. I can also show that 6 cache misses of any sort will do
the same thing. So what?
: application, but some of our RT applications have threads which run
: for a very short time (read from blocking device, compute a new value
: and write, place the recently read value into SHM, unlock a semaphore
: and read again (block)).
This is mistake #1 made by inexperienced coders in this area. It's funny,
Mr Gooch, that I've encountered this sort of problem before, including
in systems that had orders of magnitude more than your claimed 50 man
years invested in the system, and yet somehow these systems managed
to get rid of processes that woke up, read one thing, wrote one thing,
released a lock, and went back to sleep.
Wanna know why they fixed it? Because it is a brain dead way of gathering
data, and that was immediately obvious to all but the most inexperienced
programers. When I pointed out that that was their problem they were
horribly embarrassed and went and fixed it. None of them (and I can
think of at least 4 different occasions where customers were doing this,
that doesn't count the internal cases) sat around and tried to tell me
that the OS needed to fix this problem. You are unique in that respect
and I'm not sure that's the sort of uniqueness one should foster.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/