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