Re: [patch] lockless, scalable get_pid(), for_each_process() elimination, 2.5.35-BK

[Cort Dougan]

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 [e-mail]
} More majordomo info at  http://vger.kernel.org/majordomo-info.html
} Please read the FAQ at  http://www.tux.org/lkml/