2008-09-25 00:10 that was fun 2008-09-25 00:11 beach cruiser on the strand at midnight 2008-09-25 00:11 can't get more california than that 2008-09-25 00:49 -!- pgquiles(~pgquiles@42.Red-83-39-60.dynamicIP.rima-tde.net) has joined #tux3 2008-09-25 01:04 -!- ajonat(~ajonat@190.48.120.246) has joined #tux3 2008-09-25 01:07 bah 2008-09-25 01:18 flipsout: enjoy it before winter hits 2008-09-25 01:53 -!- pgquiles_(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-09-25 03:19 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-25 04:19 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3 2008-09-25 05:00 -!- pgquiles_(~pgquiles@42.Red-83-39-60.dynamicIP.rima-tde.net) has joined #tux3 2008-09-25 05:08 -!- Kirantpatil(~kiran@122.167.196.127) has joined #tux3 2008-09-25 05:09 -!- Kirantpatil(~kiran@122.167.196.127) has left #tux3 2008-09-25 11:09 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-25 11:11 file_bwrite: block write <0:0> 2008-09-25 11:11 <<< extent 0x0/4 >>> 2008-09-25 11:11 0 entry groups: 2008-09-25 11:11 file_bwrite: fill gap at 0x0/4 2008-09-25 11:11 balloc_extent_from_range: balloc 4 blocks from [0/1000] 2008-09-25 11:11 balloc extent -> [2/4] 2008-09-25 11:12 extent writing almost happening 2008-09-25 11:12 lots of combinatorics to take care of 2008-09-25 11:53 segs: 0x2/4 (1) 2008-09-25 11:53 dwalk_mock: add entry key 0x4 after 0x0 2008-09-25 11:53 dwalk_mock: add extent 0x2/4 2008-09-25 11:53 getting closer... 2008-09-25 11:57 -!- amey(~amey@116.73.35.180) has joined #tux3 2008-09-25 12:02 -!- amey(~amey@116.73.35.180) has left #tux3 2008-09-25 12:33 -!- tim_dimm_(~mobile@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-25 12:57 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3 2008-09-25 14:07 fyi, I might be late for tux3 U.. hopefully not... 2008-09-25 14:23 bah 2008-09-25 15:23 -!- Ryback_(~ulisses@201.82.39.16) has joined #tux3 2008-09-25 17:03 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-25 18:49 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-09-25 18:55 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-25 19:14 -!- Kirantpatil(~kiran@122.167.212.31) has joined #tux3 2008-09-25 19:14 -!- Kirantpatil(~kiran@122.167.212.31) has left #tux3 2008-09-25 19:33 -!- ajonat(~ajonat@190.48.120.246) has joined #tux3 2008-09-25 19:56 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-25 19:57 I'll miss tonight's Tux3 U 2008-09-25 19:57 looking forward to reading the logs 2008-09-25 20:02 present 2008-09-25 20:02 although were's everyone else 2008-09-25 20:02 i'm here 2008-09-25 20:03 just got back from an offsite 2008-09-25 20:03 whiskey, steak, and guns ;-) 2008-09-25 20:04 okay, so I chose wine instead of whiskey 2008-09-25 20:04 so that makes it 2008-09-25 20:04 wine, steak and guns ... 2008-09-25 20:05 and I might be getting the order a little mixed up since I'm a little tini-iny-bit buzzed 2008-09-25 20:05 so it might just have been 2008-09-25 20:05 guns, steak, and wine... 2008-09-25 20:05 hmm 2008-09-25 20:05 where's the teacher? 2008-09-25 20:09 heh, tonight you get to teach instead 2008-09-25 20:10 nope 2008-09-25 20:10 I'm close to calling myself drunk... I need a nap. 2008-09-25 20:11 flipsout: ping pong? 2008-09-25 20:12 I believe Razvan was supposed to be the teacher this time around 2008-09-25 20:12 but he's RzM|Away, apparently afk 2008-09-25 20:13 maze 2008-09-25 20:13 here 2008-09-25 20:13 ok 2008-09-25 20:13 cool 2008-09-25 20:13 where were we 2008-09-25 20:13 any requests? 2008-09-25 20:13 last one was bio xfrs 2008-09-25 20:13 then last tuesday we skipped 2008-09-25 20:13 right, conducted by maze 2008-09-25 20:13 it was good 2008-09-25 20:14 now tux3fs has a rather nice generic set of bio fns 2008-09-25 20:14 an async and a sync bio transfer flavor 2008-09-25 20:14 right 2008-09-25 20:14 fully general, except maybe it could take some alloc flags 2008-09-25 20:14 alloc flags? 2008-09-25 20:14 yes, like how hard the kernel should try to satisfy a request 2008-09-25 20:15 you will see that functions like kmalloc take gfp flags 2008-09-25 20:15 memory wise or io wise? 2008-09-25 20:15 "gfp: get free pages" 2008-09-25 20:15 memory wise 2008-09-25 20:15 well 2008-09-25 20:15 is coupled to io 2008-09-25 20:15 in an incestuous way 2008-09-25 20:15 most of the time, the kernel cache will be just about full 2008-09-25 20:16 what we have now I believe asks for memory in a 'can sleep' way 2008-09-25 20:16 except for right after boot, or after unmounting a volume, say, which invalidates a bunch of cache 2008-09-25 20:16 unless you specify GFP_ATOMIC, it is always "can sleep" 2008-09-25 20:16 also when you delete a dvd you just checksummed ;-) 2008-09-25 20:16 so that io transfers can take place and other things can run while waiting for memory to get free 2008-09-25 20:17 we have __NOFAIL as a gfp flag 2008-09-25 20:17 just means it will try for infinity... 2008-09-25 20:17 it means, under no circumstances return without completing the allocation 2008-09-25 20:17 until it suceeds 2008-09-25 20:18 yes 2008-09-25 20:18 and what could prevent it from succeeding? 2008-09-25 20:18 asking for 100M on 50M machine 2008-09-25 20:18 true 2008-09-25 20:18 or 120M machine with 20+M already allocated 2008-09-25 20:18 or not enough memory of a specific type 2008-09-25 20:18 or on a 200M machine on which 195M has leaked 2008-09-25 20:19 (ie. asking for low memory, when only high mem is free) 2008-09-25 20:19 also true 2008-09-25 20:19 [or dma16 or dma32] 2008-09-25 20:19 but the most common reason is: when memory is full of dirty pages that cannot be written out for some reason 2008-09-25 20:19 in general it is a bug 2008-09-25 20:20 in general, memory can always be allocated in kernel, by kicking out some cache 2008-09-25 20:20 so writing out dirty pages should not need to allocate memory, since otherwise it can deadlock? 2008-09-25 20:20 or you need to have a pre-allocated pool of temporary pages 2008-09-25 20:20 I believe the kernel even provides such features 2008-09-25 20:21 exactly 2008-09-25 20:21 you nailed that 2008-09-25 20:21 in fact, this is an unsolved problem in linux kernel 2008-09-25 20:21 or it is solved, but the fix is not in mainline 2008-09-25 20:21 see bio-throttle 2008-09-25 20:22 there has been an attempt to fix the problem by limiting total memory that is allowed to be dirty in kernel 2008-09-25 20:22 "dirty limits" 2008-09-25 20:22 complex, fragile, and doesn't work 2008-09-25 20:22 but has been good for creating lots of bugfixing activity lately 2008-09-25 20:22 anyway 2008-09-25 20:22 enough on memory for now? 2008-09-25 20:23 I think so... 2008-09-25 20:23 this is just something to be aware of off? 2008-09-25 20:23 let's get back to __copy2 2008-09-25 20:23 get you thinking about it, yes 2008-09-25 20:23 and some practical facts about GFP_ flags to memory allocators 2008-09-25 20:24 when you allocate a bio, there is an attempt made to provide a pre-allocated pool, so in theory a bio alloc will never fail 2008-09-25 20:25 in practice, it can slow to a craw as the pre-allocated pool only gaurantees 2 bios 2008-09-25 20:25 and it often gets into that corner 2008-09-25 20:25 hmm, so should you keep a couple pre-alloced bios for yourself? 2008-09-25 20:26 youcan maintain your own pool, yes 2008-09-25 20:26 perhaps a good idea when the kernel is in the broken state it is 2008-09-25 20:26 extra complexity 2008-09-25 20:26 see the "mempool" mechanism 2008-09-25 20:27 is it worth it? 2008-09-25 20:27 better is to fix the bug 2008-09-25 20:27 it works for some situations 2008-09-25 20:27 its messy 2008-09-25 20:28 much harder to fix bugs, then to work around them ;-) 2008-09-25 20:28 the first requires understanding the entire system 2008-09-25 20:28 the second only the way it affects you 2008-09-25 20:28 true 2008-09-25 20:28 we can return to that issue 2008-09-25 20:29 it is fully understood, but not by everybody 2008-09-25 20:29 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2063 <- _2copy 2008-09-25 20:29 I'm totally mystified by the name, 2copy 2008-09-25 20:29 as we all are 2008-09-25 20:29 speaking of all 2008-09-25 20:29 how many of us are here? 2008-09-25 20:29 I'm feeling lonely 2008-09-25 20:30 [and drunk...] 2008-09-25 20:30 heh 2008-09-25 20:30 we'll keep it light then 2008-09-25 20:30 and short 2008-09-25 20:30 I'm attempting to get feeling drunk ;) 2008-09-25 20:30 you're well ahead it would seem 2008-09-25 20:30 heh 2008-09-25 20:31 yea, 2 glasses of white (some pinot), and 2 of red (not sure what it was), plus steak, plus an afternoon at a gun range 2008-09-25 20:31 the gun range made you drunk I presume 2008-09-25 20:31 wine before or after shooting? 2008-09-25 20:31 nah, that was first, and was fun ;-) 2008-09-25 20:31 the range was first 2008-09-25 20:32 afterward you rode around and shot up a few stop signs? 2008-09-25 20:32 nah, we left the range gun-less 2008-09-25 20:32 just checking 2008-09-25 20:32 we then invaded an italian restaurant in downtown mountain view 2008-09-25 20:33 castro street? 2008-09-25 20:33 yep 2008-09-25 20:34 ok, 2copy 2008-09-25 20:34 right 2008-09-25 20:34 seems we're pretty much alone 2008-09-25 20:35 the basic scheme is: alloc page; ->prepare write; copy data onto it; ->commit_write 2008-09-25 20:35 the -> are calls into the filesystem 2008-09-25 20:36 interesting 2008-09-25 20:36 what's the purpose of the prepare? 2008-09-25 20:36 the channel log will be preserved for posterity 2008-09-25 20:36 verify there's enough disk space, etc? 2008-09-25 20:36 I've alwasy wonder about that 2008-09-25 20:36 yes including the comments about wine 2008-09-25 20:36 for a partial page write, the prepare does a read before write 2008-09-25 20:36 otherwise it seems pretty useless 2008-09-25 20:36 I think it is useless 2008-09-25 20:37 but it has been in linux since eternity, which is an argument for it staying another eternity 2008-09-25 20:37 how do you know if it's a partial or full page write? 2008-09-25 20:37 see the parameters passed to it 2008-09-25 20:37 and where they come from 2008-09-25 20:37 ah 2008-09-25 20:37 this comes from the file pos and write len 2008-09-25 20:38 2159 status = a_ops->prepare_write(file, page, offset, offset+bytes); 2008-09-25 20:38 so there may be a partial page at the beginning and one at the end 2008-09-25 20:38 so I'm assuming that the 3rd and 4th paramts 2008-09-25 20:38 are 0,4096 if we're writing a full page 2008-09-25 20:38 pretty dumb to have the ->prepare on every page when only two per transfer need the special treatment 2008-09-25 20:38 oh, moment 2008-09-25 20:38 3rd 0 2008-09-25 20:38 do we call prepare_write, commit_write per page 2008-09-25 20:38 otherwise right 2008-09-25 20:38 or on page ranges 2008-09-25 20:39 per page 2008-09-25 20:39 dumb 2008-09-25 20:39 actually, this whole part of the kernel sucks pretty hard 2008-09-25 20:39 why just 3rd 0, why not 4th PAGE_SIZE (4096)? 2008-09-25 20:40 4th is normally page_size, yes 2008-09-25 20:40 ok 2008-09-25 20:40 3rd is zero normally because it's an offset 2008-09-25 20:40 in the page 2008-09-25 20:40 right hence the 0,4096 above I was asking about 2008-09-25 20:40 see the flush_dcache page 2008-09-25 20:41 ah 2008-09-25 20:41 sorry, read wrong 2008-09-25 20:41 oki 2008-09-25 20:41 the dcache flush is a noop on x86 2008-09-25 20:41 some arches need it 2008-09-25 20:41 mips I think 2008-09-25 20:41 what's the purpose? 2008-09-25 20:41 tlb hackery? 2008-09-25 20:41 could not swear to that 2008-09-25 20:41 also not really clear to me 2008-09-25 20:41 it's like L1 cache 2008-09-25 20:42 that has to be explicitly flushed 2008-09-25 20:42 why... another matter 2008-09-25 20:42 seems like braindamage to design a processor that doesn't know how to flush its cache 2008-09-25 20:42 but people do it, they have their reasons I suppose 2008-09-25 20:42 maybe the asm code can be much more efficient on some archs if you assume explicit flushes on any change 2008-09-25 20:43 put that one aside to bother the mips maintainer about 2008-09-25 20:43 there is some sparse kernel doc on the subject 2008-09-25 20:43 but there is a general principle here: just because your code works on x86 does not mean it works 2008-09-25 20:44 hmm 2008-09-25 20:44 same is true if all your spinlocks work, because you compiled with smp disabled 2008-09-25 20:44 so how do you test on the dozen+ archs linux supports? 2008-09-25 20:44 get users to report errors? 2008-09-25 20:44 that's the question isn't it? 2008-09-25 20:44 after testing on the 2-3 you have access to? 2008-09-25 20:44 well, I can test smp 32 and 64 bit x86 2008-09-25 20:44 you try to be aware of the issues and write using the generic apis that work on every arch 2008-09-25 20:44 I could probably get my hands on power32 and maybe alpha 2008-09-25 20:45 and eventually, somebody with that arch will hit your bug and complain 2008-09-25 20:45 but that's about it 2008-09-25 20:45 right... 2008-09-25 20:45 but... 2008-09-25 20:45 it's good to test on a couple different arches 2008-09-25 20:45 bugs like that are damn near impossible to trace down 2008-09-25 20:45 big/lttle end 2008-09-25 20:45 is any of the archs the most difficult to program for? 2008-09-25 20:45 and if one can find it, maybe something that has to do explicit dcache flush and other such horrors 2008-09-25 20:45 (I know alpha has the most lenient memory cache coherency model) 2008-09-25 20:45 sparc maybe 2008-09-25 20:46 sparc is pretty horrible 2008-09-25 20:46 who still has sparc machines? 2008-09-25 20:46 pretty much complete absence of atomic instructions 2008-09-25 20:46 dave miller 2008-09-25 20:46 sparc maintainer 2008-09-25 20:46 sun has the niagara box 2008-09-25 20:46 well, hopefully the maintainer does ;-) 2008-09-25 20:46 but it's true, sparc is nearly dead 2008-09-25 20:46 arm 2008-09-25 20:47 arm is embedded 2008-09-25 20:47 on the rise 2008-09-25 20:47 it's a big constituency these days 2008-09-25 20:47 easy to find, hard to find with a lot of ram or power or disk 2008-09-25 20:47 would testing in emulators work? 2008-09-25 20:47 if it has such a great mips/watt ratio you'd expect to see it in hpc 2008-09-25 20:48 some sort of qemu or something? 2008-09-25 20:48 but it's not there 2008-09-25 20:48 makes me wonder 2008-09-25 20:48 about that mips/watt ratio 2008-09-25 20:48 of arm? 2008-09-25 20:48 yes 2008-09-25 20:48 arm is good for stuff which needs high mips 2008-09-25 20:48 but rarely 2008-09-25 20:48 possilby you can test in emulation 2008-09-25 20:48 ie. high peak, but mostly idle 2008-09-25 20:48 I think qemu is x86 only 2008-09-25 20:48 i've been doing a lot of stuff on amd geode and intel atom if that helps, i can test something, they're low end but still powerful 2008-09-25 20:48 but those are x86 aren't tyhey? 2008-09-25 20:49 bushman, they' 2008-09-25 20:49 bushman, they're x86 arch 2008-09-25 20:49 but testing is _always_ useful 2008-09-25 20:49 x86 is a sick arch... but it's so dominant 2008-09-25 20:49 true 2008-09-25 20:49 POS86 2008-09-25 20:49 hmm no idea what that is 2008-09-25 20:50 you'll decode it eventually ;) 2008-09-25 20:50 are we done with _2copy? 2008-09-25 20:50 oh piece of 2008-09-25 20:50 balance_dirty_pages_ratelimited(mapping); <- attempt to limit kernel dirty pages 2008-09-25 20:50 so it goes a page at a time right? 2008-09-25 20:50 nasty thing 2008-09-25 20:50 yes, yuck 2008-09-25 20:51 and even then it's a mess 2008-09-25 20:51 there are many different flavors of similar kinds of io transfer loops 2008-09-25 20:51 in filemap.c 2008-09-25 20:51 take a browse and enjoy some of them 2008-09-25 20:52 oh, look at that vmtruncate at the end 2008-09-25 20:52 scary stuff 2008-09-25 20:52 why is there so much of it? 2008-09-25 20:52 much of what? 2008-09-25 20:52 copy loops? 2008-09-25 20:52 code;-) 2008-09-25 20:52 badly designed 2008-09-25 20:52 or not designed at all 2008-09-25 20:52 just grows 2008-09-25 20:53 changes in response to bug reports 2008-09-25 20:53 it feels like we have multiple interfaces/apis for everything 2008-09-25 20:53 including performance bug reports 2008-09-25 20:53 you're starting to get a feeling for it 2008-09-25 20:53 and eventually none of them get fully tested 2008-09-25 20:53 it's not unmanageable, just unconscionable 2008-09-25 20:53 at least not in all the myriad of combinations 2008-09-25 20:54 they get pretty well tested 2008-09-25 20:54 hmm 2008-09-25 20:54 I _think_ pretty much all buffer wries get funneled through _2copy 2008-09-25 20:54 though I haven't completely read through since this thing landed 2008-09-25 20:54 here's a question then 2008-09-25 20:54 how would I go about tracing a syscall 2008-09-25 20:55 seeing exactly which kernel funcs 2008-09-25 20:55 linux trace toolkit 2008-09-25 20:55 got called in what order with what params? 2008-09-25 20:55 puts probes into the kernel 2008-09-25 20:55 dprobe? kprobe? 2008-09-25 20:55 http://www.opersys.com/LTT/ 2008-09-25 20:55 kprobe 2008-09-25 20:55 now part of ltt I think 2008-09-25 20:55 hmm, so that's the 2nd time you've mentioned ltt 2008-09-25 20:56 it's good I take it? 2008-09-25 20:56 I haven't used it 2008-09-25 20:56 I should 2008-09-25 20:56 but it's the only game in town 2008-09-25 20:56 I think 2008-09-25 20:56 latest news is 2004 2008-09-25 20:56 I think that may because it got at least partially merged 2008-09-25 20:57 http://ltt.polymtl.ca/ 2008-09-25 20:57 moved 2008-09-25 20:58 right 2008-09-25 20:58 it current 2008-09-25 20:58 to 2.6.27-rc7 2008-09-25 20:58 current to yesterday or so ;) 2008-09-25 20:58 I should try it, there are no doubt many times when it could have saved me time 2008-09-25 20:59 patch-2.6.27-rc7-lttng-0.26.tar.bz225-Sep-2008 16:05 177K - right 2008-09-25 21:00 we should have looked at grab_cache_page in _2copy 2008-09-25 21:00 another poorly named function 2008-09-25 21:00 but important, and it will serve as our introduction the the page cache api 2008-09-25 21:00 Find or create a page at the given pagecache position. Return the locked 2038 * page. This function is specifically for buffered writes. 2008-09-25 21:00 one of the worst apis in the kernel ;) 2008-09-25 21:01 2038? 2008-09-25 21:01 line # 2008-09-25 21:01 oh 2008-09-25 21:01 what does page cache position mean? 2008-09-25 21:01 index within the cache for a particular inode 2008-09-25 21:01 so many logical pages offset in the file 2008-09-25 21:01 so a page cache position is a superblock:inode:offset triplet? 2008-09-25 21:02 just inode:offset 2008-09-25 21:02 because inode->sb 2008-09-25 21:02 ah 2008-09-25 21:02 so now inode #, but instead inode ptr 2008-09-25 21:02 yes 2008-09-25 21:02 s/now/not/ 2008-09-25 21:02 the "page cache" is in fact not a single cache 2008-09-25 21:02 maybe it was at one time 2008-09-25 21:03 but now it is a radix tree that hangs off of each inode 2008-09-25 21:03 giving you an idea maybe how bloating things get with lots of small files 2008-09-25 21:03 so page cache is effectively per inode? 2008-09-25 21:03 and what a bad idea sysfs is, which uses files and all the cache stuff that goes with it, to communicate tiny, 4 byte quantities, to the kernel 2008-09-25 21:04 page cache is per inode 2008-09-25 21:04 not effectively, absolutely 2008-09-25 21:04 why this split to per inode level? 2008-09-25 21:05 we think it's a good idea 2008-09-25 21:05 doesn't it make it harder to find what to free when memory runs low? 2008-09-25 21:05 no, because all the pages are linked together via a lru list 2008-09-25 21:05 but anyway 2008-09-25 21:05 lru is probably a bad idea 2008-09-25 21:05 lru = least recently used 2008-09-25 21:05 yes 2008-09-25 21:05 self organizing list 2008-09-25 21:06 simple minded 2008-09-25 21:06 just for the folks reading this later 2008-09-25 21:06 not very effective, especially since we mostly bypass it 2008-09-25 21:06 who bypasses it? 2008-09-25 21:06 we do 2008-09-25 21:06 in writeout for example 2008-09-25 21:06 it's mostly per-inode using the inode dirty lists 2008-09-25 21:07 we, as in tux 2008-09-25 21:07 or we as in fs drivers? 2008-09-25 21:07 there as in linuxen 2008-09-25 21:07 we as in linux penguins 2008-09-25 21:08 hmm 2008-09-25 21:08 the lru has exaclty one purpose: to decide which page to evict next 2008-09-25 21:08 we mess with the lru idea so much that we don't get good decisions on that 2008-09-25 21:09 what do you mean mess? 2008-09-25 21:09 all kinds of mess 2008-09-25 21:09 there is the concept of hot and cold end of the lru list 2008-09-25 21:09 does it evict both clean and dirty page? 2008-09-25 21:10 and there is code to try to move pages to the hot or cold end of the list according to whether we think the page is hot or cold 2008-09-25 21:10 both clean and dirty 2008-09-25 21:10 actually only clean 2008-09-25 21:10 it cleans dirty pages 2008-09-25 21:10 and evicts clean pages 2008-09-25 21:10 yes, to prefer using hot pages, since those are likely to be in cache 2008-09-25 21:10 so we won't be wasting cache by using hot pges 2008-09-25 21:10 right, except I think we mostly blow chunks in deciding what will be hot 2008-09-25 21:11 sinc the caches of hot page, can replace spot of previous page 2008-09-25 21:11 yes, evicting pages that wil be faulted in again immediately does no good, quite the contrary 2008-09-25 21:12 or read via filesystem operations 2008-09-25 21:12 ok, it's getting late 2008-09-25 21:12 true 2008-09-25 21:12 and I'm falling asleep 2008-09-25 21:12 see you 2008-09-25 21:12 ;-) 2008-09-25 21:13 should be time for questions now 2008-09-25 21:13 overtime 2008-09-25 21:13 and since I've been asking questions all session... 2008-09-25 21:13 I'll let other folks ask questions now 2008-09-25 21:13 next tuesday we will continue with grab_cache_page 2008-09-25 21:14 finally 2008-09-25 21:14 ;-) 2008-09-25 21:14 -!- ChanServ changed mode/#tux3 -> +o flips 2008-09-25 21:14 Topic for #tux3 is: Tux3 list membership roars past 100! ~ http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 p.m. Pacific Time ~ Next session: grab_cache_page and friends 2008-09-25 21:14 -!- flips changed mode/#tux3 -> -o shapor 2008-09-25 21:15 -!- flips changed mode/#tux3 -> -o flips 2008-09-25 21:15 yeah, tried changing that earlier and failed 2008-09-25 21:15 I'll unlock the topic 2008-09-25 21:15 nah 2008-09-25 21:15 anyway, let's find a bed 2008-09-25 21:16 -!- ChanServ changed mode/#tux3 -> +o flips 2008-09-25 21:16 Topic for #tux3 is: Tux3 list membership roars past 100! ~ http://tux3.org ~ Tux3 U, right here Tuesdays and Thursdays at 8 p.m. Pacific Time ~ Next session: grab_cache_page and friends 2008-09-25 21:16 -!- flips changed mode/#tux3 -> -o flips 2008-09-25 21:16