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 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"