Ted Unangst wrote: > Michal Mazurek wrote: > > There is what appears to be a sensless hash in kern_synch.c. It's an > > array of 128 TAILQs which are hashed according to the high bits of the > > wchan. It's possible to write a program that adds kern.maxthread entries > > to one of those TAILQs. Just running chrome with 11 tabs open adds 35 > > entries to one TAILQ, while leaving others empty. > > > > If it doesn't matter that a user program can make a TAILQ very long, > > then the hash is senseless (diff below). > > > > If it does matter, then it's broken, and a different data structure > > needs to be used. Currently RB trees require all element values to be > > unique, > > but a version of RB trees with non-unique element values is possible. > > > > Any thoughts? > > I don't think this is a good change. it's going backwards. even if there's 100 > things waiting on the same thing, there are other procs that aren't waiting on > it.
Yeah, if anything, we might want a better distribution. FreeBSD XOR the shifted bits with the wait channel (and uses a 256 bucket table). In my limited testing it doesn't seem to make much of a difference thoughm, I need to come up with a better workload for this.
