Messages in this thread | | | From | Cort Dougan <> | Date | Wed, 18 Sep 2002 11:35:51 -0600 | Subject | Re: [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK |
| |
It's also not a bad idea to sometimes say "Linux cannot do that". Trying to make the system do _everything_ will result in it doing many things very poorly.
} Again, you're talking about entirely theoretical numbers that have no } relevance for real life. } } Sure, you can do that. But a real life box? Nope. } } > Or in 1.25 hours } > on an 8-way box. And then we are back to step #1: trying to pass over } > already allocated PIDs by destroying the contents of the L1 and L2 cache } > once for each allocated PID passed. } } So? It happens very rarely, and.. } } > Sure, with 2 billion PIDs space that } > averages out, but it's an algorithm with a very nasty worst-case behavior, } > which is not so hard to trigger. } } ... the worst-case-behaviour is basically impossible to trigger with any } real load. } } The worst case does not happen for "100k threads" like you've made it } sound like. } } The worst case happens for "100k threads consecutive in the pid space". } } Which means that not only do you have to roll over, you have to roll over } with a humungous number of threads _still_ occupying their old consecutive } positions when you roll over. } } I repeat: you're making up schenarios that simply have no relevance to } real life. } } Linus } } - } To unsubscribe from this list: send the line "unsubscribe linux-kernel" in } the body of a message to majordomo@vger.kernel.org } More majordomo info at http://vger.kernel.org/majordomo-info.html } Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |