Back to Home / #uml / 2007 / 04 / Prev Day | Next Day
#uml IRC Logs for 2007-04-24

---Logopened Tue Apr 24 00:00:41 2007
00:08|-|shze [~shze@c-69-245-63-191.hsd1.tn.comcast.net] has quit [Ping timeout: 480 seconds]
00:24|-|sbw [~silasb@c-67-188-208-20.hsd1.ca.comcast.net] has quit [Quit: Leaving]
00:33|-|strontian [~nobody@kekkonen.cs.hut.fi] has quit [Server closed connection]
00:33|-|strontian [~nobody@kekkonen.cs.hut.fi] has joined #uml
00:39|-|shze [~shze@c-69-245-63-191.hsd1.tn.comcast.net] has joined #uml
02:08|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has quit [Ping timeout: 480 seconds]
02:57|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has joined #uml
03:12|-|shze [~shze@c-69-245-63-191.hsd1.tn.comcast.net] has left #uml [Konversation terminated!]
03:22|-|desaster [desaster@fe.dc.344a.static.theplanet.com] has joined #uml
03:24|-|AllenJB [~ajb42@raptor.ukc.ac.uk] has quit [Quit: Lost terminal]
03:24|-|weasel [weasel@weasel.noc.oftc.net] has quit [Quit: Reconnecting]
03:24|-|weasel [weasel@asteria.debian.or.at] has joined #uml
03:59|-|AllenJB [~ajb42@raptor.ukc.ac.uk] has joined #uml
04:07|-|polyonymous [~hacker@pd953a589.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
04:20|-|polyonymous [~hacker@pd953b458.dip0.t-ipconnect.de] has joined #uml
04:25|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
05:59|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has quit [Remote host closed the connection]
06:58|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has joined #uml
07:33|-|strontian [~nobody@kekkonen.cs.hut.fi] has quit [Ping timeout: 480 seconds]
07:54|-|krau [~cktakahas@200.184.118.132] has joined #uml
08:59|-|aroscha [~aroscha@213.235.234.114] has joined #uml
09:01|-|aroscha [~aroscha@213.235.234.114] has quit []
09:02|-|jdike [~jdike@pool-71-174-247-179.bstnma.fios.verizon.net] has joined #uml
09:02<jdike>Hi guys
09:54|-|ElectricElf [~dbharris@electricelf.netrep.oftc.net] has quit [Read error: Operation timed out]
09:55<albertito>jdike: hi!
10:07|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
10:09<baroni>jdike: hi
10:20|-|hfb [~hfb@pool-72-67-156-130.lsanca.dsl-w.verizon.net] has joined #uml
10:20|-|hfb [~hfb@pool-72-67-156-130.lsanca.dsl-w.verizon.net] has left #uml []
10:27|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has quit [Ping timeout: 480 seconds]
11:02|-|karrde_ [karrde@bzq-88-153-58-221.red.bezeqint.net] has joined #uml
11:03|-|karrde_ [karrde@bzq-88-153-58-221.red.bezeqint.net] has quit []
11:08|-|the_hydra [~mulyadi@125.164.99.201] has joined #uml
11:09<aroscha>hi!
11:10<aroscha>jdike: so I have some better stats now with 1500 instances. This might be interesting: http://texas.funkfeuer.at
11:10<the_hydra>aroscha: hi, you started 1500 instances of UML?
11:10<aroscha>click on status display to get to the full munin stats
11:11<aroscha>the_hydra: yes
11:11<the_hydra>aroscha: great!
11:11<jdike>there's a big cloud on top of the graphs
11:11<aroscha>they are all connected to one single linux bridge
11:12<aroscha>but!! since 1500 instances regularly (every second or so) want to send their routing topology to all other nodes on the bridge we have a theoretic traffic volume of 1500^2 packets/sec
11:12<aroscha>which is quite insane
11:13<aroscha>and another thing that I noticed is that the system is totally busy with context switches
11:13<aroscha>and each instance basically suffers heavily from starvation
11:13<aroscha>so...
11:13<jdike>you might make HZ very low
11:14<aroscha>they are there and running but only a few of them actually do somethings
11:14<aroscha>jdike: what would that help? less timer IRQs?
11:14<jdike>HZ == 100 * 1500 instances == 150000 interrupts/sec
11:14<aroscha>ahhh
11:14<the_hydra>at least they are woken up less
11:14|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
11:14<the_hydra>jdike: UML should work with NO_HZ?
11:15<jdike>I don't know what arch support is needed for that yet
11:15<jdike>but yes
11:15<the_hydra>jdike: I mean, on the guest side...
11:15<aroscha>jdike: but http://texas.funkfeuer.at/munin/localdomain/localhost.localdomain.html#System tells me that the IRQ rate is 500 irqs/sec
11:15<the_hydra>hmm
11:15<jdike>those are hardware IRQs
11:15<aroscha>ah ok
11:15<aroscha>you mean softirqs?
11:16<aroscha>yes, actually I wanted to ask if there is any good reference where I can learn more about how UML schedules things
11:16<jdike>no
11:16<jdike>to UML they are hardware IRQs
11:16<jdike>but have nothing to do with host hardware IRQs
11:17<the_hydra>aroscha: UML schedules thing under the "mercy" of host OS scheduler
11:17<jdike>it schedules things the same as any other Linux box
11:17<the_hydra>aroscha: so whatever host decides, UML follow...jeff, CMIIW
11:18<aroscha>that is because each process inside the UMLs are seen on the host's side ?
11:18<the_hydra>yes, in host kernel land
11:19<the_hydra>bot not quite "visible" in host user land
11:19<aroscha>ok
11:19<the_hydra>jdike: pls cmiiw
11:19<the_hydra>s/bot/but
11:19<the_hydra>aroscha: of course, you would see them all in TT mode
11:19<the_hydra>but I guess you're running using SKAS 0/3
11:19<aroscha>skas0
11:20<jdike>the fact that UML processes are visible on the host is an implementation artifact
11:20<jdike>they're not with skas3
11:20<aroscha>yes makes it hard to count :)
11:20<jdike>and that has no effect on UML scheduling
11:20<aroscha>i know, that is also why i wanted to have skas3 on 64 bit hehe
11:20<aroscha>ok. good to know
11:20<jdike>on the host, they are all stopped, except for the one that the UML scheduler has chosen to run
11:21<aroscha>and inside the other UMLs? does their time progress?
11:21<jdike>when they are scheduled by the host
11:21<aroscha>but their internal timecounter is not updated when they are ready/blocked from the host's perspective?
11:23<jdike>no
11:23<jdike>but it catches up when it gets some time
11:28<aroscha>hmmm, that is quite interesting for simulations. because that means we have different notions of time in each instance
11:29[~]aroscha will read the papers from 2000 etc. to learn more...
11:30<aroscha>jdike: if I were to re-program the uml_switch. Then packets going thru uml_switch would still travel to the host's userland and back into the kernel again, right? Two times
11:30|-|wyvern [~wyvern@69-12-176-23.dsl.dynamic.sonic.net] has quit [Read error: Operation timed out]
11:34<jdike>aroscha, time is jumpy, but will generally stay in sync
11:34<jdike>yup, in and out of host userspace
11:43|-|wyvern [~wyvern@69-12-176-23.dsl.dynamic.sonic.net] has joined #uml
12:19|-|kos_tom [~thomas@humanoidz.org] has joined #uml
13:07|-|mjf [~mjf@r5bb59.net.upc.cz] has joined #uml
13:18|-|Urgleflogue [~plamen@87-126-143-181.btc-net.bg] has joined #uml
13:18<the_hydra>jdike: I listened to your podcat in scmagazine, quite amusing
13:19<jdike>amusing?
13:19<the_hydra>grrr, i mean podcast
13:19<jdike>meow
13:19<caker>where's that?
13:19[~]caker wants
13:19<the_hydra>I intend to use that to practice my English listening :)
13:19<jdike>caker, the one with you in it prolly
13:19<jdike>actually, no
13:19<caker>oh... :)
13:19<jdike>maybe the one I did in Sydney
13:20<caker>so many podcasts, ya know?
13:20<the_hydra>yeah, you and caker
13:20<the_hydra>scmagazine.com IIRC
13:20[~]caker has been syndicated
13:20<jdike>yeah, that actually was the only podcast
13:20<jdike>the Sydney thing was recorded, but only for notes
13:20<jdike>not a podcast
13:33|-|ElectricElf [~dbharris@electricelf.netrep.oftc.net] has joined #uml
14:09|-|the_hydra [~mulyadi@125.164.99.201] has quit [Quit: gtg all]
14:42|-|strontian [~nobody@kekkonen.cs.hut.fi] has joined #uml
15:07|-|krau [~cktakahas@200.184.118.132] has quit [Ping timeout: 480 seconds]
16:18|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
16:29|-|mjf [~mjf@r5bb59.net.upc.cz] has quit [Quit: leaving]
17:03|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
17:05[~]aroscha is back and in the mood to break some UML instance
17:05<jdike>uh oh
17:06<aroscha>;-) meaning: testing
17:12|-|kos_tom [~thomas@humanoidz.org] has quit [Quit: I like core dumps]
17:45<aroscha>hehe
17:45<aroscha>found a prob
17:45<aroscha>(or I used a wrong option)
17:46<aroscha>#
17:46<aroscha>#
17:46<aroscha>#
17:46<aroscha># mount none /mnt/pub/ -t hostfs -o /public_uml/init -o ro
17:46<aroscha>slab error in verify_redzone_free(): cache `size-32': double free detected
17:46<aroscha>Call Trace:
17:46<aroscha>61167be8: [<6006616f>] kmem_cache_free+0xaa/0xb3
17:46<aroscha>61167bf8: [<60064010>] __slab_error+0x1f/0x21
17:46<aroscha>61167c08: [<60065713>] cache_free_debugcheck+0xc2/0x1a4
17:46<aroscha>61167c10: [<600b7899>] hostfs_fill_sb_common+0xf1/0x112
17:46<aroscha>61167c38: [<600b77a8>] hostfs_fill_sb_common+0x0/0x112
17:46<aroscha>61167c48: [<600661ed>] kfree+0x75/0xbe
17:46<aroscha>61167c78: [<600b7899>] hostfs_fill_sb_common+0xf1/0x112
17:46<aroscha>61167ca8: [<6006a714>] get_sb_nodev+0x55/0x95
17:46<aroscha>61167ce8: [<600b78ce>] hostfs_read_sb+0x14/0x16
17:46<aroscha>61167cf8: [<6006a85e>] vfs_kern_mount+0x52/0x8e
17:46<aroscha>61167d38: [<6006a8d9>] do_kern_mount+0x3f/0x59
17:46<aroscha>61167d78: [<6007c9c8>] do_new_mount+0x5f/0x92
17:46<aroscha>61167db8: [<6007d0f1>] do_mount+0x1a3/0x1cf
17:46<aroscha>61167de8: [<60015c3d>] copy_from_user_skas+0x7a/0x7c
17:46<aroscha>61167e18: [<6007ce68>] exact_copy_from_user+0x66/0xa0
17:46<aroscha>61167e58: [<6007cf09>] copy_mount_options+0x67/0xac
17:46<aroscha>61167e98: [<6007d3e9>] sys_mount+0x84/0xc8
17:46<aroscha>61167ef8: [<60015605>] handle_syscall+0x65/0x80
17:46<aroscha>61167f08: [<60014474>] segv_handler+0x68/0x6e
17:46<aroscha>61167f28: [<6002505b>] handle_trap+0xd0/0xdb
17:46<aroscha>61167f68: [<600254e6>] userspace+0x139/0x181
17:46<aroscha>61167fc8: [<6001532e>] fork_handler+0x86/0x8d
17:46<aroscha>0000000060b7b178: redzone 1:0x5a2cf071, redzone 2:0x5a2cf071.
17:46<aroscha>mount: mounting none on /mnt/pub/ failed
17:46<aroscha>#
17:53<aroscha>when I strace it I can find out that lstat will complain about the file "none"
17:53<aroscha>AFAIK I wrote the mount cmd according to the docs
18:10<aroscha>ahh!
18:10<aroscha>maybe the sentence in the docs <quote>Note that hostfs is currently not available on 2.5. The reason is that there was an fs.h rework early in 2.5 which required filesystem changes, and I haven't got around to updating hostfs to those changes.</quote> means 2.5 and 2.6 ?
18:31<albertito>aroscha: I'm using hostfs as root with the latest 2.6...
18:32<albertito>aroscha: I had an issue yesterday (and sent a patch) but today I've been using it all day long installing packages and building stuff and it seems stable
18:46<aroscha>albertito: May I ask you how you mounted things?
18:46<aroscha>I really followed the docs
18:47<aroscha>and for me it really looks like the docu is not up to date
18:47<aroscha>mount is searching for a file "none"
18:47<aroscha>which is a bit bogus
18:48<albertito>aroscha: I'm using root over hostfs, like this:
18:49<albertito>aroscha: root=/dev/root rootfstype=hostfs rootflags=/path/to/the/root/dir
18:50<albertito>aroscha: let me try mounting one
18:50<aroscha>ah!
18:50<aroscha>you use udev?
18:51<albertito>aroscha: and this worked just fine inside the same UML: mount -t hostfs -o /tmp none x/
18:51<albertito>aroscha: no, I don't
18:51<aroscha>works
18:51<aroscha>same here
18:51<aroscha>strange
18:52<albertito>aroscha: well, I do on the host, but not on the guest. But udev makes no difference there because it's still kernel initialization time, there is no userspace at that point (so udev has a long way before it gets started)
18:52<aroscha>the order of parameters matters!
18:52<albertito>aroscha: !
18:52<aroscha>(udev) agreed. I don't use it either
18:52<albertito>aroscha: anyway, it shouldn't break like that, so it looks like there's a bug somewhere =)
18:53<aroscha>yes, well... I really copy and pasted the lines from the docu
18:53<aroscha>so...
18:53<aroscha>I hope jdike sees that
18:53<aroscha>jdike: ?
18:53<aroscha>docu update?
18:53<aroscha>albertito: thanks!
18:54<albertito>aroscha: you're welcome!
20:34<jdike>aroscha, there have been some recent bug fixes in hostfs
20:34<jdike>try rc7 and see if that BUG goes away
20:34<aroscha>jdike: basically I really just had to re-order the parameters
20:34<aroscha>that was all
20:36<jdike>well, there's nothing you should be able to do which can cause a double-free
20:36<jdike>so, it's still a bug
20:44|-|jdike [~jdike@pool-71-174-247-179.bstnma.fios.verizon.net] has quit [Quit: Leaving]
20:53|-|hfb [~hfb@adsl-75-39-161-90.dsl.irvnca.sbcglobal.net] has joined #uml
20:55|-|hfb [~hfb@adsl-75-39-161-90.dsl.irvnca.sbcglobal.net] has left #uml []
21:08|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
22:25|-|baroni [~baroni@c906a072.virtua.com.br] has quit [Ping timeout: 480 seconds]
22:34|-|baroni [~baroni@c906a072.virtua.com.br] has joined #uml
23:02|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
23:21|-|shze [~shze@c-69-245-63-191.hsd1.tn.comcast.net] has joined #uml
---Logclosed Wed Apr 25 00:00:23 2007