Linus Torvalds wrote:Actually I had quoted that, made a reply, and decided that my reply was too close to a flame and deleted the quote and the nasty reply, because I couldn't find a nice way to say what I wanted. Oh well, I tried to keep to a higher level, but... on this topic you seem to be off on an ego trip. You are not the decider, George Bush is the decider, and the only time he's not wrong he didn't understand the question. I checked the schedule, it's not you week to be God. There are sensible people you respect on other topics, who have the opinion that there is room for behaviors other than CFS, and who have created a pluggable scheduler framework which they are trying to hand you on a platter. And you won't even consider that they might be right, because you believe there can be one scheduler which is close to optimal for all loads. Unfortunately not so, I've been looking at schedulers since MULTICS, and desktops since the 70s (MP/M), and networked servers since I was the ARPAnet technical administrator at GE's Corporate R&D Center. And on desktops response is (and should be king), while on a server, like nntp or mail, I will happily go from 1ms to 10sec for a message to pass through the system if only I can pass 30% more messages per hour, because in virtually all cases transit time in that range is not an issue. Same thing for DNS, LDAP, etc, only smaller time range. If my goal is <10ms, I will not sacrifice capacity to do it. Because people who run servers for a living, and have to live with limited hardware capacity realize that latency isn't the only issue to be addressed, and that the policy for degradation of latency vs. throughput may be very different on one server than another or a desktop. Because people can't get you to understand that one size doesn't fit all (and I doubt I've broken through). The real issue is that you can't imagine that people who don't share your opinion are not only wrong but don't understand the problem. You may be right, but when you say anyone who disagrees is wrong by definition, then you have lost sight of productive technical differences. When your arguments drop to personal attacks and rants it's time to look at your technical values. Exactly, and I'm not the only one who doubts that more than one model would be useful. I'm sorry you can't see that about CPU schedulers as well. I don't disagree with you lightly, in this case I think I have a better superficial understanding of schedulers than you do of how production servers are used. -- bill davidsen <davidsen@tmr.com> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -
| Glauber de Oliveira Costa | [PATCH 0/19] desc_struct integration |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| jmerkey | [ANNOUNCE] mdb: Merkey's Linux Kernel Debugger 2.6.27-rc4 released |
| Oliver Pinter | Re: x86: 4kstacks default |
git: | |
| Linus Torvalds | Re: VCS comparison table |
| Mark Junker | git on MacOSX and files with decomposed utf-8 file names |
| Junio C Hamano | Re: More precise tag following |
| Len Brown | fatal: unable to create '.git/index': File exists |
| Mayuresh Kathe | Re: What is our ultimate goal?? |
| Diana Eichert | Re: OpenBSD on decTOP? |
| Richard Stallman | Real men don't attack straw men |
| knitti | Re: HP Procurve or Soekris w. OpenBSD ? |
| Mark Lord | Re: 2.6.25-rc8: FTP transfer errors |
| Andi Kleen | [PATCH RFC] [1/9] Core module symbol namespaces code and intro. |
| Ritesh Kumar | SO_RCVBUF doesn't change receiver advertised window |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
