He did post some more about it, but I didn’t reprint it on the page. I hope to have improved mailing list archives up soon, so that may make the conversation accessible.

The old token code was (IIRC) per-CPU, meaning that when a thread on one CPU needed to grab the token of another CPU, and IPI message gets sent to the owning CPU in order to make the switch. In order for threads on the original owning CPU to get the token back so that they can continue doing what they are doing, another IPI message would be sent off to the new CPU owning the token. That is part of the cause of the overhead that made the old token code inefficient, along with the fact that threads had to enter into a critical section in order to acquire the tokens, preventing IPI messaging a token away.

The new token code, from the description in the mailing lists, and on the DragonFly site say nothing about the new code, except that threads no longer need to enter into a critical section to get a token, and that any number of threads may aquire and hold a token at once, but that only one of those threads will be running at any given time.

Is this a global (as in not per-CPU) serialization; does this mean that (for an extreme example) if *every* thread on an SMP system holds the same token, that only *one* of them will run? Is this the reason for the rumors of poor performance in DF after the newtoken commit?

The explanation on DragonFlyBSD.org is really not very clear here, and I’m not exactly that adept yet at reading kernel source code. Could anyone here fill me in? I would be greatful.