Re: Patch for inode SLIST conversion

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

     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.

						-Matt