Patch for inode SLIST conversion
dillon at apollo.backplane.com
Sun Jan 20 18:14:22 PST 2008
Keep in mind that tokens have virtually no aquisition or release
overhead. If you read the lwkt_gettoken() code path carefully you
will notice that it doesn't actually have to do all that much...
it doesn't even need to get a spinlock once the token is passively
owned by the originating cpu, so applications which use tokens
heavily will be running a very optimal code path. And the token
tracking structure is declared on the stack, meaning it is virtually
guarenteed to be in the cpu's L1 cache.
All the token handling complexity occurs ONLY when a thread blocks
while holding a token. This doesn't happen very often and is not
considered to be a critical code path. The integration of the
token code with the LWKT thread scheduler allows the scheduler to
simply refrain from scheduling threads whos tokens cannot be
immediately acquired, avoiding the wakeup/return-to-sleep loops
that other locks have to deal with. It also gives the tokens a
very specific operating mechanic that is extremely useful for
iterating over global system lists without having to worry about
lock order reversals or anything else.
More information about the Kernel