Tokens
2006 Jun 20 10:36:34 <@hsu> buggs: you know that tokens haven't worked out very well in dfly, right?
2006 Jun 20 10:36:58 <@buggs> hsu, no
2006 Jun 20 10:37:07 <ar> they didn't?
2006 Jun 20 10:37:10 <@buggs> tell me more
2006 Jun 20 10:37:11 <@hsu> yeah, Matt says so in all his talks
2006 Jun 20 10:37:23 <@hsu> I think he also replaced the token uses in vfs w/ spinlocks
2006 Jun 20 10:37:35 <@hsu> let me double-check that
2006 Jun 20 10:38:15 <@hsu> don't see that in the 1.4 sources
2006 Jun 20 10:38:21 <@corecode> yes
2006 Jun 20 10:38:34 <@corecode> he switched the token implementation to spinlocks
2006 Jun 20 10:38:37 <@corecode> that's one thing
2006 Jun 20 10:38:37 <@hsu> but basically, yeah, it wasn't one of the better new concepts
2006 Jun 20 10:38:51 <@corecode> and he switched most of the code to spinlocks as well
2006 Jun 20 10:39:04 <@corecode> the problem is that as you give them up when blocking
2006 Jun 20 10:39:16 <@buggs> i seem to have missed that on the lists
2006 Jun 20 10:39:25 <@corecode> you need to write code that handles situations which *potentially* block
2006 Jun 20 10:39:30 <@buggs> i wasn't aware the tokens and spinlocks where mutually
2006 Jun 20 10:39:39 <@corecode> so each time you allocate something
2006 Jun 20 10:39:47 <@corecode> you need to loop again
2006 Jun 20 10:39:55 <@corecode> because your variables might have become stale
2006 Jun 20 10:40:10 <@hsu> so the problems with tokens were they were relatively expensive
2006 Jun 20 10:40:39 <@hsu> and giving up the token when you blocked made it hard to code many things in the kernel
2006 Jun 20 10:40:52 <@buggs> i thought them to be on the same level as the new subsystem locks in freebsd
2006 Jun 20 10:41:05 <@hsu> because there were some calls like malloc which blocked
2006 Jun 20 10:41:13 <@buggs> meaning each subsystem has a token for itself
2006 Jun 20 10:41:20 <@buggs> which it could lend to others
2006 Jun 20 10:41:27 <@hsu> and so you couldn't call them w/ tokens held and still have any sort of guarantees
2006 Jun 20 10:41:37 <@hsu> same for free()
2006 Jun 20 10:41:44 <@corecode> yah
2006 Jun 20 10:41:54 <@corecode> i think we should do a lot of RCU
2006 Jun 20 10:42:00 <@corecode> and taskqueues
2006 Jun 20 10:42:14 <@corecode> and we just should have one taskqueue thread per cpu
2006 Jun 20 10:42:26 <@corecode> and not per subsystem one per cpu
2006 Jun 20 10:42:47 <@corecode> even if we lose code locality
2006 Jun 20 10:43:14 <@hsu> well, code locality is the whole point, so that's a big thing to lose
2006 Jun 20 10:43:27 <@hsu> it's what makes modern systems go fast
2006 Jun 20 10:43:40 <@buggs> well then i might be able to proof the problems of tokens
2006 Jun 20 10:43:48 <@hsu> i-cache misses are more deadly than d-cache misses now
2006 Jun 20 10:43:49 <@buggs> or find another thing to do proofs about
2006 Jun 20 10:44:23 <@hsu> buggs: have you looked into RCU? someone just tried to write a proof of it, but I don't think it was a very good paper
2006 Jun 20 10:44:52 <@buggs> i only read some abstracts
2006 Jun 20 10:44:56 --> maudib (~andre@gprs-pool-1-023.eplus-online.de) has joined #dragonflybsd
2006 Jun 20 10:45:20 <@hsu> i have a suspicion that RCU can better be formulated in terms of Dijstra's logical clocks, but haven't sat down to work out the formulation yet
2006 Jun 20 10:45:57 <@buggs> i'm trying to apply Fagin's "Reasoning about Knowledge"
