Messages in this thread |  | | | From | (Larry McVoy) | | Subject | Re: Scheduling Times --- Revisited | | Date | Mon, 28 Sep 1998 02:12:39 -0600 |
| |
I said: : > I'd like to start out by saying I feel crappy about my part in this : > whole discussion. I'm good at proving I have more to learn. I : > don't want to discourage people like Richard - that isn't the right : > answer. The right answer is to help him do better work and : > encourage better thinking, in a supportive way, and I haven't done : > that. So I'm sorry for screwing that up, that's my problem.
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/
|  |