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
} 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.
} To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
} the body of a message to email@example.com
} 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 firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:23 EST