2008-09-30 00:00 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3 2008-09-30 00:00 MaZe, hello 2008-09-30 00:07 hi pranith 2008-09-30 00:09 flips, no reply from shapor :( 2008-09-30 00:09 about the struct fields description... 2008-09-30 00:09 may be u can reply ? ;) 2008-09-30 00:09 right 2008-09-30 00:11 pranith, have you read the comment that begins: /* Leaf index format 2008-09-30 00:11 ? 2008-09-30 00:11 in dleaf.c 2008-09-30 00:11 i tried :) 2008-09-30 00:12 the header contains the two level index followed by the table of extents 2008-09-30 00:13 i dint understand the limit on number of versions at the same level 2008-09-30 00:13 dinner time for me 2008-09-30 00:14 ohkies 2008-09-30 00:14 it's simple: you can't have more than 255 entries in one group, therefore can't have more than 255 entries with the same logical address 2008-09-30 00:14 well 2008-09-30 00:14 actually that is probably wrong now 2008-09-30 00:15 hmm, anything changed? 2008-09-30 00:15 you can have multiple dleaf groups with the same logical address now I think 2008-09-30 00:15 sure, lots of code changed 2008-09-30 00:15 every day 2008-09-30 00:15 later... 2008-09-30 00:15 okies 2008-09-30 01:59 folks 2008-09-30 01:59 ACTION is back from a night of goofing off 2008-09-30 01:59 feels great 2008-09-30 01:59 I was working myself into the ground much of last week 2008-09-30 02:14 -!- ajonat(~ajonat@190.48.120.169) has joined #tux3 2008-09-30 02:14 -!- orgthingy(~orgthingy@62.150.55.188) has joined #tux3 2008-09-30 02:14 -!- hirofumi(~hirofumi@210.171.168.39) has joined #tux3 2008-09-30 02:14 -!- SEJeff(~jeff__@66.151.59.138) has joined #tux3 2008-09-30 02:14 -!- pgquiles(~pgquiles@166.Red-88-16-39.dynamicIP.rima-tde.net) has joined #tux3 2008-09-30 02:14 -!- konrad(~konrad@D-128-208-53-208.dhcp4.washington.edu) has joined #tux3 2008-09-30 02:14 -!- flips(~phillips@phunq.net) has joined #tux3 2008-09-30 02:14 -!- ceatinge(~ceatinge@72.232.13.50) has joined #tux3 2008-09-30 02:14 -!- nataliep(~nataliep@207.47.98.129.static.nextweb.net) has joined #tux3 2008-09-30 02:14 -!- data(~data@echo489.server4you.de) has joined #tux3 2008-09-30 02:14 -!- Bushman(~marcin@c-76-23-106-132.hsd1.sc.comcast.net) has joined #tux3 2008-09-30 02:14 -!- shapor(~shapor@yzf.shapor.com) has joined #tux3 2008-09-30 02:14 -!- vcgomes(~vcgomes@li17-238.members.linode.com) has joined #tux3 2008-09-30 02:14 -!- ChanServ changed mode/#tux3 -> -o tux3bot 2008-09-30 02:31 -!- kbingham(~kbingham@193.132.141.186) has joined #tux3 2008-09-30 03:01 -!- pgquiles(~pgquiles@166.Red-88-16-39.dynamicIP.rima-tde.net) has joined #tux3 2008-09-30 03:26 -!- Kirantpatil(~kiran@122.166.94.37) has joined #tux3 2008-09-30 03:26 hello 2008-09-30 03:26 ah, what a great night ^______^ 2008-09-30 03:35 -!- Kirantpatil(~kiran@122.166.94.37) has left #tux3 2008-09-30 03:35 -!- Kirantpatil(~kiran@122.166.94.37) has joined #tux3 2008-09-30 03:53 orgthingy, where from/ 2008-09-30 03:53 ? 2008-09-30 03:54 why everybody keeps asking where im from xD 2008-09-30 04:10 why? you have a problem in that/ 2008-09-30 04:17 pranith : well, not really 2008-09-30 04:17 but i dont usually say any personal info in IRC :P 2008-09-30 04:18 ohk 2008-09-30 04:18 i dint knw that ones country is personal 2008-09-30 04:20 hi pranith 2008-09-30 04:21 Kirantpatil, helo 2008-09-30 04:21 is the session over today morning ? 2008-09-30 04:22 again i failed join .. 2008-09-30 04:22 TUX 3 university session. 2008-09-30 04:23 hmm 2008-09-30 04:23 yeah, morning is a bad time for people here 2008-09-30 04:23 i too miss it 2008-09-30 04:23 usually get it from the logs 2008-09-30 04:23 i am from bengaluru.. 2008-09-30 04:24 how about you.. 2008-09-30 04:24 delhi 2008-09-30 04:24 oh cool.. 2008-09-30 04:24 what do u do? 2008-09-30 04:24 i run Freesoftware training center.. 2008-09-30 04:24 oh 2008-09-30 04:24 which place in bangy? 2008-09-30 04:25 Driver programming, Administration.. 2008-09-30 04:25 it is in rajaji nagar. 2008-09-30 04:25 hmm 2008-09-30 04:25 i knw only koramangala 2008-09-30 04:25 and marathahalli 2008-09-30 04:25 ok.. 2008-09-30 04:25 and mg road ;) 2008-09-30 04:26 i am planning for giving filesystem training. 2008-09-30 04:26 so i am preparing for it.. 2008-09-30 04:26 oh 2008-09-30 04:26 nice 2008-09-30 04:26 i have it scheduled from Nov 1. 2008-09-30 04:27 hmm 2008-09-30 04:27 too soon i guess 2008-09-30 04:27 hope for getting some contributors ... 2008-09-30 04:27 oh 2008-09-30 04:27 which level are the students here? 2008-09-30 04:28 basically they span from college grads to experienced fellows.. 2008-09-30 04:28 hmm 2008-09-30 04:28 ok 2008-09-30 04:29 my motives are to spread linux kernel programming in easy way 2008-09-30 04:30 here is our website www.turtlelinuxlabs.in 2008-09-30 04:30 nice 2008-09-30 04:31 i am still in learning phase of filesystems.. 2008-09-30 04:32 hmm 2008-09-30 04:32 i tried to apply the patch of daniels posted in lwn.net and compile the kernel.. 2008-09-30 04:32 it was showing some error. 2008-09-30 04:34 give me some guidelines on this.. 2008-09-30 04:37 which patch? 2008-09-30 04:37 tux3 is not yet in kernel 2008-09-30 04:38 its still in userspace in fuse 2008-09-30 04:38 you dont need to compile the kernel to test this 2008-09-30 04:38 just use the fuse version 2008-09-30 04:39 please see this http://lwn.net/Articles/299740/ 2008-09-30 04:39 i followed that link.. 2008-09-30 04:41 hmm, i think i missed that 2008-09-30 04:41 :( 2008-09-30 04:41 what shall i do then.. 2008-09-30 04:41 flips, why dont u cc to tux3?? 2008-09-30 04:42 im not sure.. 2008-09-30 04:42 ive never compiled this in a kernel before.. 2008-09-30 04:43 where can i get the fuse version.. 2008-09-30 04:48 am i doing right here.. 2008-09-30 04:51 hmm 2008-09-30 04:51 use the mercurial repo 2008-09-30 04:52 hg pull http://phunq.net/tux3 2008-09-30 04:52 install mercurial 2008-09-30 04:53 ok, i will try that 2008-09-30 04:57 then cd tux3/user/test 2008-09-30 04:57 make && make debug 2008-09-30 04:58 it will mount in /tmp/ 2008-09-30 05:04 thanks pranith. 2008-09-30 05:12 welcome :) 2008-09-30 05:13 i am getting some errors, shall i paste it here 2008-09-30 05:13 i am using ubuntu gibbon. 2008-09-30 05:15 tux3.c:14:18: error: popt.h: No such file or directory 2008-09-30 05:16 sudo apt-get install libpopt-dev 2008-09-30 05:34 Kirantpatil, worked? 2008-09-30 05:42 yes it worked. 2008-09-30 05:43 i am just execting sudo make testfuse 2008-09-30 05:50 ok.. i played with testfuse and testfs 2008-09-30 05:50 they are working fine.. 2008-09-30 05:51 next what should i do ?? 2008-09-30 05:51 work with dleaf and dleaftest 2008-09-30 05:51 make dleaf 2008-09-30 05:51 make dleaftest 2008-09-30 05:51 ./dleaf 2008-09-30 05:51 there is a bug with testfuse 2008-09-30 05:51 in readdir... 2008-09-30 05:52 ls 2008-09-30 05:52 touch hello 2008-09-30 05:52 ls 2008-09-30 05:52 rm hello 2008-09-30 05:52 ls 2008-09-30 05:53 i am now installing valgrind 2008-09-30 05:54 no need 2008-09-30 05:54 u can run it directly 2008-09-30 05:54 ./dleaf 2008-09-30 05:54 ok.. 2008-09-30 05:57 i did run ./dleaf 2008-09-30 05:57 it is showing lot of dwalk messages.. 2008-09-30 05:58 i didnt understand where should i do "touch hello" "ls" and "rm hello" 2008-09-30 06:00 make debugfs 2008-09-30 06:00 "make debug" 2008-09-30 06:00 go to /tmp/test 2008-09-30 06:00 them do touch and rm then ls 2008-09-30 06:03 yeah 2008-09-30 06:03 root@kiran-desktop:/tmp/test# ls 2008-09-30 06:03 ???@???? 2008-09-30 06:04 this is how looks after "rm hello" 2008-09-30 06:04 mode 0100666 uid 0 gid 0 root d:1 2008-09-30 06:04 ---- get attr for '/' ---- 2008-09-30 06:04 ---- get attr for '/' ---- 2008-09-30 06:04 ---- readdir '/' at 0 ---- 2008-09-30 06:04 ---- get attr for '� 2008-09-30 06:04 @�' ---- 2008-09-30 06:04 ---- get attr for '/� 2008-09-30 06:04 @�' ---- 2008-09-30 06:04 ---- readdir '/' at 1000 ---- 2008-09-30 06:05 in debug message. 2008-09-30 06:10 then i think i need to understand the code .. 2008-09-30 06:10 am i right.. 2008-09-30 06:13 yup 2008-09-30 06:13 u need to.. 2008-09-30 06:13 something wrong in readdir 2008-09-30 06:13 i dint look further 2008-09-30 06:49 -!- Kirantpatil(~kiran@122.166.94.37) has left #tux3 2008-09-30 07:33 -!- pgquiles_(~pgquiles@62.43.226.52.static.user.ono.com) has joined #tux3 2008-09-30 07:41 flips, there? 2008-09-30 07:47 -!- pgquiles__(~pgquiles@166.Red-88-16-39.dynamicIP.rima-tde.net) has joined #tux3 2008-09-30 09:21 -!- orgthingy(~orgthingy@62.150.55.188) has joined #tux3 2008-09-30 09:27 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-30 09:38 -!- RazvanM(~RazvanM@dazzler.isi.jhu.edu) has joined #tux3 2008-09-30 09:49 -!- Kirantpatil(~kiran@122.167.222.94) has joined #tux3 2008-09-30 09:49 -!- Kirantpatil(~kiran@122.167.222.94) has left #tux3 2008-09-30 09:50 -!- Kirantpatil(~kiran@122.167.222.94) has joined #tux3 2008-09-30 09:50 -!- Kirantpatil(~kiran@122.167.222.94) has left #tux3 2008-09-30 09:52 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-30 10:28 -!- Kirantpatil(~kiran@122.167.222.94) has joined #tux3 2008-09-30 10:28 -!- Kirantpatil(~kiran@122.167.222.94) has left #tux3 2008-09-30 10:48 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-30 10:51 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-30 12:01 -!- orgthingy(~orgthingy@62.150.55.188) has joined #tux3 2008-09-30 12:43 -!- MaZe(~MaZe@216-239-45-4.google.com) has joined #tux3 2008-09-30 17:10 -!- konrad(~konrad@D-128-208-53-208.dhcp4.washington.edu) has joined #tux3 2008-09-30 18:58 -!- ajonat(~ajonat@190.48.107.189) has joined #tux3 2008-09-30 19:32 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-30 19:52 19:52:21 2008-09-30 19:54 that's true 2008-09-30 19:54 ah, and I missed the ping from pranith too 2008-09-30 19:54 yesterday 2008-09-30 19:55 I guess I'd better fix the readdir bug in fuse 2008-09-30 19:55 specially as a provisional fix has been offered 2008-09-30 19:55 -!- ajonat_(~ajonat@190.48.122.185) has joined #tux3 2008-09-30 19:59 t -30 & counting 2008-09-30 20:00 t -> tux3 2008-09-30 20:00 browsers running? 2008-09-30 20:00 mayhaps 2008-09-30 20:01 we start here: http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2040 2008-09-30 20:01 or maybe we should start from where this is called in _copy2 2008-09-30 20:01 _2copy 2008-09-30 20:01 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2106 2008-09-30 20:02 -!- RazvanM(~RazvanM@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-09-30 20:02 razvanm: http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2106 2008-09-30 20:02 -!- RalucaM(~ral@pool-151-196-118-156.balt.east.verizon.net) has joined #tux3 2008-09-30 20:02 ACTION is sorry that he is late 2008-09-30 20:02 flips: razvanm: http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2106 2008-09-30 20:02 ACTION is glad you're here 2008-09-30 20:02 page = __grab_cache_page(mapping, index); 2008-09-30 20:03 ok, we're getting a cache page that user data will be copied onto 2008-09-30 20:03 later that page will be added to a bio and thrown at a device 2008-09-30 20:03 but today we're just going to look at the page cache 2008-09-30 20:04 that is, the list of pages belonging to a particular inode that have been read in via some buffer IO operation 2008-09-30 20:04 or directly created, as here 2008-09-30 20:04 since we know we're going to write to this page, normally the entire thing, there is no need to read it first 2008-09-30 20:05 we just "grab" it, and by that, viro means look into the cache and allocated a page if one is not already there 2008-09-30 20:06 so lets got to http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2040 and see how it works 2008-09-30 20:06 quick q: this "grab" is unique to this case? 2008-09-30 20:06 pretty much 2008-09-30 20:06 page cache ops are highly non-orthogonal 2008-09-30 20:06 there may or may not be justification for that 2008-09-30 20:07 they just kind of grew from usage, like most of linux 2008-09-30 20:07 and the comment claims it's just for buffered writes 2008-09-30 20:07 possibly true 2008-09-30 20:07 should we take a look at what mapping and index? :P 2008-09-30 20:08 struct address_space * mapping 2008-09-30 20:08 we'll be looking at those, yes 2008-09-30 20:08 aaa... this was in some time ago 2008-09-30 20:08 that's what this is all about 2008-09-30 20:08 pgoff_t index; 2008-09-30 20:08 index is for practical purposes unsigned int 2008-09-30 20:08 that means 32 bit on 32 arches 2008-09-30 20:08 interesting that pgoff_t seems to be a page offset, but it would make sense to be a file offset div page_size ? 2008-09-30 20:09 maybe just a misnomer 2008-09-30 20:09 limiting the size of any file to 2^(32 + 12) 2008-09-30 20:09 oh, as in offset into file in pages 2008-09-30 20:09 exactly 2008-09-30 20:10 bad terminology 2008-09-30 20:10 -!- Kirantpatil(~kiran@122.167.219.78) has joined #tux3 2008-09-30 20:10 does this mean files can't be larger than 16TB? 2008-09-30 20:10 (on 32-bit arch) 2008-09-30 20:10 yes 2008-09-30 20:10 that's where that comes from 2008-09-30 20:10 volumes too 2008-09-30 20:10 does any linux filesystem workaround this somehow? 2008-09-30 20:10 volumes? 2008-09-30 20:10 because each volume has a page cache dedicated to non-file pages on the volume, that is, metadata 2008-09-30 20:11 there is no workaround 2008-09-30 20:11 "speed of sound in a 32 bit vacuum" 2008-09-30 20:11 :p 2008-09-30 20:11 :D 2008-09-30 20:11 ok, what does the index index? 2008-09-30 20:11 A: a radix tree 2008-09-30 20:12 let's drill down into find_lock_page, which is used in more than one place thankfully 2008-09-30 20:12 index = pos >> PAGE_CACHE_SHIFT; 2008-09-30 20:12 so how does tux3 scale beyond this? 2008-09-30 20:12 it doesn't? 2008-09-30 20:12 razvanm, good point 2008-09-30 20:13 razvanm, you will see code like that in tux3.c 2008-09-30 20:13 it does not on 32 bit 2008-09-30 20:13 fact of life 2008-09-30 20:13 ACTION sits down in the back row 2008-09-30 20:13 hey shapor 2008-09-30 20:13 hi flips 2008-09-30 20:13 ACTION throws some chalk 2008-09-30 20:13 always wanted to do that 2008-09-30 20:13 is it illegal yet? 2008-09-30 20:14 so you simply can't mount such a large tux3 fs on a 32-bit os? 2008-09-30 20:14 simply can't 2008-09-30 20:14 we'd better produce a nice error though 2008-09-30 20:14 because somebody will try 2008-09-30 20:14 hm 2008-09-30 20:14 to tell the truth, it would not be that big a deal to fix 2008-09-30 20:14 somebody who wants to is welcome 2008-09-30 20:15 pretty easy hack for a great deal of fame 2008-09-30 20:15 ACTION listens for the thundering herd of volunteers 2008-09-30 20:15 ok, let's go to find_lock_page 2008-09-30 20:15 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L661 2008-09-30 20:16 takes a mapping and index 2008-09-30 20:16 mapping is what tux3 calls "map" 2008-09-30 20:16 I called it map because that saved me about 80,000 keystrokes over the life of the project 2008-09-30 20:17 how does a page become a pagecache page? 2008-09-30 20:17 also, a tux3 userspace map maps blocks, whereas linux page cache maps pages 2008-09-30 20:17 shapor, we're looking at that right now 2008-09-30 20:17 somewhere in here we will find an alloc_pages(order 1) 2008-09-30 20:17 order 0 I mean 2008-09-30 20:18 first thing we do is try to find it already in the radix tree, but let's skip that and find out what happens when it's not there 2008-09-30 20:18 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3 2008-09-30 20:18 nothing happens :P 2008-09-30 20:18 exactly 2008-09-30 20:18 this function does not allocate pages 2008-09-30 20:18 alloc_pages(order n) allocates 2^n pages, with linear physical addresses? 2008-09-30 20:19 Returns zero if the page was not present. 2008-09-30 20:19 ok, let's go back up to _2copy and find out where the page is really alloced 2008-09-30 20:19 if we don't find it here 2008-09-30 20:20 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2049 2008-09-30 20:20 status = -ENOMEM; 2008-09-30 20:20 break 2008-09-30 20:20 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2107 2008-09-30 20:20 2049 page = page_cache_alloc(mapping); 2008-09-30 20:21 8-) 2008-09-30 20:21 :D 2008-09-30 20:21 better ;-) 2008-09-30 20:21 right 2008-09-30 20:21 knew it was in there ;) 2008-09-30 20:22 74static inline struct page *page_cache_alloc(struct address_space *x) 75{ 76 return __page_cache_alloc(mapping_gfp_mask(x)); 77} 2008-09-30 20:22 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L500 2008-09-30 20:22 which is just a call to alloc_pages 2008-09-30 20:22 as promised 2008-09-30 20:22 return alloc_pages(gfp, 0); 2008-09-30 20:22 what is the point of page_cache_alloc? 2008-09-30 20:23 some new bs about mapping_gfp_mask 2008-09-30 20:23 calling __page_cache_alloc 2008-09-30 20:23 if (cpuset_do_page_mem_spread()) { 2008-09-30 20:23 for numa 2008-09-30 20:23 shapor, probably little point if you really dig 2008-09-30 20:23 lots of accumlated cruft in there 2008-09-30 20:23 why grabing fails if adding to the lru fails? 2008-09-30 20:23 it's basically a numa-diverse alloc_pages(0) 2008-09-30 20:24 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2057 2008-09-30 20:24 goto repeat; 2008-09-30 20:24 notice it shouldn't fail 2008-09-30 20:24 razvanm, because that got a lot more complex recently 2008-09-30 20:24 let's take a look at it 2008-09-30 20:25 getting well outside the scope of vfs 2008-09-30 20:25 I guess there must be a reason why the page must be in the lru. Is there an obvious one? :P 2008-09-30 20:25 I think every page must be 2008-09-30 20:25 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L459 <- :P 2008-09-30 20:25 otherwise how do you know what to flush on memory low condition? 2008-09-30 20:25 it's about reverse mapping 2008-09-30 20:26 lots of complexity has been added to optimize it 2008-09-30 20:26 oh sorry 2008-09-30 20:26 I was blathering 2008-09-30 20:26 O:-) 2008-09-30 20:26 truth is, it's just a wrapper for the radix tree insert 2008-09-30 20:26 MaZe: to deal with the low memory you need some of the pages to be there :P 2008-09-30 20:27 add to page cache should never, ever fail 2008-09-30 20:27 but it could 2008-09-30 20:27 RazvanM: I think that's with extremely low memory conditions 2008-09-30 20:27 if it does fail we are in deep doodoo 2008-09-30 20:27 :D 2008-09-30 20:27 flips: yeah i see it gets called a few times in that file 2008-09-30 20:27 not jsut extremely low, bug buggy in the kernel bug sense 2008-09-30 20:27 the page could already be there, probably we're not fully locked against smp, and thus could potentially hit this on 2 cpus 2008-09-30 20:27 shapor, yes, this is the main interface to the page cache 2008-09-30 20:28 maze, we are fully locked against smp 2008-09-30 20:28 necessarily 2008-09-30 20:28 so where does the EEXIST check come from? 2008-09-30 20:28 write_lock_irq does that, and turns off interrupts for good measure 2008-09-30 20:29 if the page is already there, somebody needs to tell us 2008-09-30 20:29 MaZe: the page is already in lru, right? 2008-09-30 20:29 not lru 2008-09-30 20:29 radix tree 2008-09-30 20:29 badly named function here 2008-09-30 20:29 very bad 2008-09-30 20:29 it means "add to page cache and also to lru" 2008-09-30 20:29 not add to lru 2008-09-30 20:30 aaaa 2008-09-30 20:30 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L490 2008-09-30 20:30 right, only adding to cache can fail 2008-09-30 20:30 got a rul for the EEXIST test? 2008-09-30 20:30 url? 2008-09-30 20:30 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2055 2008-09-30 20:31 mem_cgroup_uncharge_page <- wow, 75 cent name 2008-09-30 20:31 shapor, this should get a rise out of the hotrodder in you 2008-09-30 20:31 memory accounting for containerization 2008-09-30 20:31 hah 2008-09-30 20:32 nitro chardged pages 2008-09-30 20:32 maze, thanks 2008-09-30 20:32 for? 2008-09-30 20:32 for the comment re containers 2008-09-30 20:32 oh. 2008-09-30 20:32 explains why I haven't seen the beast before 2008-09-30 20:32 crappy name 2008-09-30 20:32 therefore fits nicely ;) 2008-09-30 20:33 cgroup is the containers stuff, both cpu and mem 2008-09-30 20:33 uncharge must be in the release page path, and charge in the alloc path 2008-09-30 20:33 yeah this unfortunately all gets pretty complex 2008-09-30 20:33 because we're supporting numa and containers 2008-09-30 20:34 why does this matter for tux3 2008-09-30 20:34 all right, the EEXIST is about what happens if somebody adds the page while we are waiting to acquire the radix tree lock 2008-09-30 20:34 ok? 2008-09-30 20:34 i thoguht we were intentially avoiding the vm 2008-09-30 20:34 page cache is vfs, not vm 2008-09-30 20:34 numa = non-uniform memory access machines (multi-socket machines) and containers (good for jails/vms/isolating users/apps, etc...) 2008-09-30 20:34 flips: right, hence my comment about not having all the locks in smp 2008-09-30 20:35 shapor, we only need to know to recognize what is mm and therefore can be ignored ;) 2008-09-30 20:35 ok 2008-09-30 20:35 maze, right then 2008-09-30 20:35 as usual ;) 2008-09-30 20:35 you get to run the next class ;) 2008-09-30 20:35 well 2008-09-30 20:35 no... 2008-09-30 20:35 got to wait and see what you hack next 2008-09-30 20:35 ACTION runs away... 2008-09-30 20:35 flips: did you feel the mini quake a while ago? 2008-09-30 20:35 shapor, no, missed it 2008-09-30 20:35 didn't feel anything up here 2008-09-30 20:36 we had a great one a month or two ago 2008-09-30 20:36 got the familly up and huddled under a door jamb 2008-09-30 20:36 anyway 2008-09-30 20:36 life in paradise 2008-09-30 20:36 right 2008-09-30 20:36 duck'n'cover 2008-09-30 20:36 ;-) 2008-09-30 20:36 where were we 2008-09-30 20:37 we've nearly done everything interesting in there 2008-09-30 20:37 yes, we did get sidetracked a little. 2008-09-30 20:37 http://lxr.linux.no/linux+v2.6.26.5/mm/filemap.c#L2055 2008-09-30 20:37 sorry ;) 2008-09-30 20:37 details of radix tree aren't that interesting 2008-09-30 20:37 could we have a little more info on mapping? 2008-09-30 20:37 the channel topic says "and friends" 2008-09-30 20:37 ok, question? 2008-09-30 20:37 who fills it in and what it is for? 2008-09-30 20:37 who fills in the mapping? 2008-09-30 20:37 2066 struct address_space *mapping = file->f_mapping; 2008-09-30 20:38 so it comes from the file, so the vfs? 2008-09-30 20:38 it's just the per-inode page cache 2008-09-30 20:38 vfs usually 2008-09-30 20:38 though filesystem can too, and some do 2008-09-30 20:38 the fs has access to the whole misshapen page cache api 2008-09-30 20:38 for better or worse 2008-09-30 20:38 you will see all the functions are EXPORT()ed 2008-09-30 20:39 not even _GPL 2008-09-30 20:39 you can write evil/fringer binary modules that use this interface 2008-09-30 20:39 fringe 2008-09-30 20:39 ok, did we do who fills it in enough? 2008-09-30 20:40 probably 2008-09-30 20:40 still don't get it ;-) but nevermind 2008-09-30 20:40 then we didn't 2008-09-30 20:40