TheGrebs.com:IRC Logs:#xen:2006:02:23

---	Log	opened Thu Feb 23 00:00:14 2006
00:03	\|-\|	cj_ [~cjcollier@216.39.139.201] has joined #xen
00:03	<cj_>	is there a known issue regarding short frames on dom0 bridges?
00:37	\|-\|	hollisb [~hollisb@adsl-67-115-102-122.dsl.sntc01.pacbell.net] has quit [Ping timeout: 480 seconds]
00:37	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
00:56	\|-\|	mooli [~muli@87.69.40.180.cable.012.net.il] has quit [Ping timeout: 480 seconds]
00:58	<cj_>	anyone ever use usb-storage with xen?
01:33	\|-\|	Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has quit [Quit: foo]
01:36	\|-\|	mooli [~muli@87.69.40.180.cable.012.net.il] has joined #xen
01:36	<Shaun>	aliguori: your not still awake are you?
01:47	\|-\|	schultmc [~schultmc@zealot.progeny.com] has quit [Remote host closed the connection]
02:16	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has joined #xen
02:19	\|-\|	horms [~horms@vagw.valinux.co.jp] has joined #xen
02:39	\|-\|	Netsplit unununium.oftc.net <-> quasar.oftc.net quits: VS_ChanLog
02:40	\|-\|	Shaun2222 [~ndci@ip68-5-63-223.oc.oc.cox.net] has joined #xen
02:40	\|-\|	Netsplit over, joins: VS_ChanLog
02:44	\|-\|	Teltariat [~tekron@h-68-164-200-156.nycmny83.dynamic.covad.net] has joined #xen
02:46	\|-\|	Shaun [~ndci@ip68-5-63-223.oc.oc.cox.net] has quit [Ping timeout: 480 seconds]
02:47	\|-\|	Shaun2222 changed nick to Shaun
02:49	\|-\|	sdog [~sdog@62.58.98.210] has joined #xen
03:19	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has joined #xen
03:21	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
03:25	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Read error: Connection reset by peer]
03:25	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
03:53	<xzu_>	startkeylogger
03:54	<Teltariat>	onoes!
04:24	\|-\|	Tempest2k [TeMpEsT2k@88-96-119-130.dsl.zen.co.uk] has joined #xen
04:32	\|-\|	xg1\|frank [~frank@212.123.98.180] has joined #xen
04:33	<Tempest2k>	im currently using xen 2 for the hide pci device feature any body no if this is possing in version 3 yet ?
04:35	\|-\|	alexandre [~Alexandre@200.138.131.88] has quit [Quit: Fui embora]
04:38	\|-\|	ivan [~ikelly@86.41.204.130] has joined #xen
04:41	<Tempest2k>	when i upgrade to 3.0.1 will i still be able to hide the network cards im using for my vservers from dom0 and specify the pci addr of each nic on config as i do now ? (i use 1 nic per vserver)
04:51	<tab>	Tempest2k: you have to use xen-unstable to have the pci passthrough feature
04:52	<Tempest2k>	ohh dont sound good im prolly better waiting to upgrade
04:53	<Tempest2k>	cheres tab :)
04:53	<Tempest2k>	after all xen 2 works
04:53	<tab>	wait for 3.0.2 then
04:54	<tab>	it will probably get the feature in
04:54	<tab>	for the record, lots of people use xen-unstable with success
04:54	<Tempest2k>	k thanks whens 3.0.2 due do you no ?
04:54	<tab>	when it's ready
04:54	<tab>	:)
04:55	<Tempest2k>	might see if i can find a spare box to put unstable on for testin then thanks
04:56	<Tempest2k>	is it configured is the unstable the same way as it is done on 2
05:03	\|-\|	horms [~horms@vagw.valinux.co.jp] has quit [Quit: Leaving]
05:03	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
05:23	\|-\|	MarkW [~MarkW@maw48.kings.cam.ac.uk] has quit [Remote host closed the connection]
05:24	<xg1\|frank>	hi! i'm using xen on a athlon64X2. Started 4 domU-Domains, which used alot cpu-power... after a few hours one of the domains crashed (no output when i switch to its console via xm console, state is "running"). how can i get more informations why this domain have crashed?
05:25	<xg1\|frank>	xen 3.0.1
05:30	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
05:49	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
06:00	\|-\|	sdfs [~sdfs@strugglers.net] has quit [Quit: leaving]
06:04	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
06:23	\|-\|	xg1\|frank [~frank@212.123.98.180] has quit [Quit: ]
06:35	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
08:01	\|-\|	cehteh [foobar@cehteh.homeunix.org] has quit [Remote host closed the connection]
08:02	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
08:42	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has joined #xen
08:52	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
09:00	\|-\|	cableman [~cableman@3E6B4910.rev.stofanet.dk] has joined #xen
09:03	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
09:05	\|-\|	anball [~anball@cpe-069-134-210-147.nc.res.rr.com] has joined #xen
09:33	\|-\|	anball [~anball@cpe-069-134-210-147.nc.res.rr.com] has quit [Quit: Leaving]
09:35	\|-\|	dme [~dme@host-84-9-60-139.bulldogdsl.com] has quit [Remote host closed the connection]
09:36	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
09:36	\|-\|	dme [~dme@host-84-9-60-139.bulldogdsl.com] has joined #xen
09:38	\|-\|	anball [~anball@cpe-069-134-210-147.nc.res.rr.com] has joined #xen
09:39	<aliguori>	anball, howdy
09:39	<aliguori>	anball, i sent you a patch re: an ioctl interface to xenstore...
09:40	<aliguori>	am curious if that would satisfy your needs
09:40	\|-\|	Lauwenmark [Lauwenmark@203-133.241.81.adsl.skynet.be] has joined #xen
09:48	<anball>	aliguori: thanks. yes i believe it will.
09:49	\|-\|	ns [~nivedita@c-67-171-181-157.hsd1.or.comcast.net] has joined #xen
09:51	\|-\|	schultmc [~schultmc@zealot.progeny.com] has joined #xen
09:57	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 480 seconds]
09:59	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
10:06	\|-\|	MarkW [~MarkW@maw48.kings.cam.ac.uk] has joined #xen
10:06	\|-\|	mode/#xen [+o MarkW] by ChanServ
10:09	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 481 seconds]
10:19	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has quit [Ping timeout: 480 seconds]
10:20	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Client exiting]
10:28	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Quit: Ex-Chat]
10:29	\|-\|	sdog [~sdog@62.58.98.210] has left #xen []
10:30	<@MarkW>	sdague: yo
10:32	\|-\|	harry_ [~harry@blueice1n1.uk.ibm.com] has joined #xen
10:42	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
10:52	\|-\|	stekloff [~stekloff@129.33.1.37] has joined #xen
11:15	\|-\|	Lauwenmark [Lauwenmark@203-133.241.81.adsl.skynet.be] has quit [Quit: ]
11:26	\|-\|	jerone [~jerone@pixpat.austin.ibm.com] has joined #xen
11:32	\|-\|	pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has joined #xen
11:41	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has quit [Quit: Leaving]
11:47	\|-\|	probonic [~probonic@host-84-9-223-181.bulldogdsl.com] has quit [Ping timeout: 480 seconds]
11:59	\|-\|	bestorga [~bestorga@129.33.1.37] has joined #xen
12:06	\|-\|	ns [~nivedita@c-67-171-181-157.hsd1.or.comcast.net] has quit [Quit: Leaving]
12:08	<sdague>	MarkW: yo back at you
12:09	<@MarkW>	sdague: So apparently we changed the prototype of arch_free_page
12:09	<@MarkW>	and that's why theres a file changed in arch/um
12:10	[~]	MarkW just did an unscientific benchmark of hg vs git
12:11	<@MarkW>	git took twice as long to clone (over git protocol), used about 3x the space, almost certainly more CPU in packing / unpacking
12:11	<@MarkW>	I like hg
12:11	<sdague>	yeh, hg doesn't feel like a hack either, which git still does to me
12:11	<@MarkW>	I'm actually getting quite impressed with the features in git. But hg is nicer to use, similarly fast, nice to hack on...
12:12	<@MarkW>	It does just about the same stuff, it's just nicer.
12:13	[~]	MarkW notes that it's also massively faster to du an hg repo, due to not having a squillion blob files in there!!!
12:17	<harry_>	Hey Mark, I have a xenidc-free usb driver working :-)
12:18	<teferi>	the only git feature that really impresses me, over any other distributed vcs, so far is git bisect
12:18	<teferi>	but everyone raves about that
12:20	\|-\|	bestorga [~bestorga@129.33.1.37] has quit [Quit: Leaving]
12:20	<murb>	harry_: just in time for the pci foo to be in unstable...
12:22	<harry_>	murb: how is the pci stuff significant? except that it helps in testing drivers.
12:22	<@MarkW>	teferi: there's a bisect extension for hg, but i've not used either
12:22	<@MarkW>	teferi: still it's a neat feature to have
12:22	<@MarkW>	harry_: well done, I'm glad to hear it
12:23	<@MarkW>	harry_: It'd be nice to get it in the tree - maybe you could think about submitting for 3.0.3, if not this release.
12:24	<harry_>	MarkW: it became a boredom limited process but now i am almost back to where i was progress might speed up.
12:24	[~]	MarkW just found a really interesting Xen panic bug in a recent pull of unstable. Updating to tip to see if something nasty has crept in.
12:24	<murb>	i'm finding x86_64 xen being completely non working atm.
12:24	<@MarkW>	harry_: I know that feeling. I've had the same problems when dealing with xenfs and xip2fs, re xenstore
12:25	<@MarkW>	murb: does the release version work for you?
12:25	<harry_>	I will get a patch out for review soon. I expect there will still be some things that people don't like. Hopefully it won't take too much longer to get it into shape.
12:25	<murb>	MarkW: good question, i've just got the i686 version working for now.
12:26	<murb>	it is on a remote machien and most of my experiements leaves the machine completly dead.
12:26	<@MarkW>	murb: The bug I just discovered is particularly entertaining - a particular series of domain create commands kills my entire machine, requires manual power cycle.
12:26	<murb>	R not even working.
12:27	<@MarkW>	Fortunately we have remote power switches.
12:27	<@MarkW>	harry_: Cool. I really want to get back into submitting lots of patches myself, I always seemed to get more work done that way, despite the overhead of readying them for submission.
12:27	<@MarkW>	Guess I just like to have something to aim for.
12:29	<murb>	MarkW: I'm thinking of building myself something i can use to short the atx reset/power pins remotely
12:29	<@MarkW>	murb: That'd be nice! I once build a remote power switch for an embedded device I was working on - that was incredibly useful, because the RTOS was a pile of pants ;-)
12:30	<@MarkW>	murb: the other really useful thing is a remote serial console. Esp. when running Xen as it lets you get to xen's keyhandlers
12:33	\|-\|	bestorga [~bestorga@129.33.1.37] has joined #xen
12:36	<murb>	MarkW: good except when you have http://www.yuri.org.uk/~murble/xencrash
12:37	<sdague>	MarkW: can you document what those commands are and get somethign on list?
12:38	<@MarkW>	sdague: I'm in the process of verifying exactly what commands can cause the crash and whether they occur in today's pull
12:38	<@MarkW>	sdague: then I'll either fix it myself, or post to the list
12:38	<sdague>	MarkW: if you get the command set, it would make a good xm-test
12:39	<sdague>	then it will ensure it doesn't regress in future
12:39	<@MarkW>	It's nothing spectacular
12:39	<@MarkW>	xm create -p domainfile
12:39	<@MarkW>	xm unpause <domid>
12:39	<@MarkW>	BANG
12:39	<sdague>	MarkW: still makes a good test :)
12:39	<@MarkW>	Fatal trap in interrupt context => whole machine hang with no auto reboot :-(
12:40	<@MarkW>	murb: Ouch, that's just nasty!
12:42	<@MarkW>	sdague: Heheh, it's worse than I thought. On this setup, Xen always crashes when a domain is unpaused.
12:44	<tonfa>	teferi: if you need new features for hg bisect, feel free to ask :)
12:46	\|-\|	ns [~niv@129.33.1.37] has joined #xen
12:46	\|-\|	harry_ [~harry@blueice1n1.uk.ibm.com] has quit [Quit: Leaving]
12:56	<sdague>	MarkW: awesome
12:57	<sdague>	MarkW: then xm-test should already be finding that
12:57	<@MarkW>	sdague: could be some weird tools mismatch
13:08	<aliguori>	hey MarkW! long time no see
13:10	<murb>	will anyone here be in Brussels this weekend?
13:15	\|-\|	xenic [~xenic@TLV62-0-120-25.bb.netvision.net.il] has joined #xen
13:29	<@MarkW>	aliguori: yo
13:29	<@MarkW>	aliguori: Xen is just totally broken on my machine :-D
13:30	<riel>	does anybody know of a reason why the balloon driver couldn't just use the page.lru list_head instead of adding its own?
13:30	<aliguori>	MarkW, did you break it?
13:30	<@MarkW>	aliguori: no, actually, this is tip from a few hours ago
13:31	<aliguori>	i have a system running tip from tuesday...
13:33	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Ex-Chat]
13:36	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
13:50	\|-\|	riel [riel@fangorn.surriel.com] has quit [Ping timeout: 480 seconds]
13:51	\|-\|	ogi [~ogi@felix.openfmi.net] has quit [Ping timeout: 480 seconds]
13:53	\|-\|	stekloff [~stekloff@129.33.1.37] has quit [Quit: Leaving]
14:01	\|-\|	ogi [~ogi@felix.openfmi.net] has joined #xen
14:02	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has quit [Remote host closed the connection]
14:20	\|-\|	surriel [riel@fangorn.surriel.com] has joined #xen
14:25	\|-\|	cableman [~cableman@3E6B4910.rev.stofanet.dk] has left #xen [Leaving]
14:28	<teferi>	hey, anyone care to answer a really simple question about cpu allocation with Xen?
14:30	<cfreak>	"don't ask to ask "
14:31	\|-\|	MarkW [~MarkW@maw48.kings.cam.ac.uk] has quit [Quit: Kopete 0.10.2 : http://kopete.kde.org]
14:33	<anball>	terefi: fire away
14:33	<anball>	* teferi
14:34	<teferi>	I have a dual-core machine with a bunch of domUs running on it. What's the optimal cpu-pinning arrangement?
14:35	<cfreak>	are your domUs cpu intensive or not?
14:35	<teferi>	cfreak: unfortuantely, I don't know yet. this is a box I'm setting up for colocation
14:35	<Shaun>	cfreak: with my experience that question doesnt matter :)
14:36	<Shaun>	cfreak: can control dom0's vcpu's anyway, it just uses them all regardless
14:36	\|-\|	surriel changed nick to riel
14:36	<Shaun>	unless you pin all vcpu's to the same cpu, which the docs say not to do...
14:37	<teferi>	so, hat should I be doing? giving two vcpus to each machine? giving one vcpu to each machine? what pinning arrangement?
14:39	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
14:40	<Shaun>	teferi: you plan on giving the guests multiple cpu's?
14:40	<teferi>	Shaun: I don't know.
14:40	<teferi>	Shaun: the Xen user manual doesn't go into much detail. I'm not sure what to do.
14:41	<Shaun>	i have a post on the Xen ML simular to what your asking...
14:41	<Shaun>	so far nobody has given me any good info really...
14:42	<Shaun>	best responce i got was from sean dague.... who basically sounded like he was saying hyperthreading was bad and to turn it off
14:42	<teferi>	it is.
14:42	<sdague>	Shaun: sorry, it isn't bad
14:43	<sdague>	in a xen context
14:43	<teferi>	it's an athlon64 x2, no hyperthreading.
14:43	<sdague>	dom0 sticks on a hyperthread, and everything else doesn't use them
14:43	<sdague>	as you noticed
14:44	<Shaun>	sdague: right now i cant get dom0 to stop using all cpu's
14:44	<Shaun>	setting maxcpus=1 makes it so that the HV/Dom0/DomU only see 1 cpu...
14:44	<sdague>	title Xen 3.0 / XenLinux 2.6
14:44	<sdague>	kernel (hd0,4)/boot/xen-3.0.gz dom0_mem=128M
14:44	<sdague>	module /boot/vmlinuz-2.6-xen0 root=/dev/sda5 ro maxcpus=1 console=tty0
14:44	<sdague>	set it on the module line, not the xen line
14:45	<Shaun>	ok let me give that a whirl.
14:45	<Shaun>	i think i tryed that though..
14:45	<sdague>	that works for me
14:45	<Shaun>	sdague: with 3.x?
14:46	<sdague>	yep
14:46	<Shaun>	sdague: you didnt happen to see my other post did you?
14:46	<sdague>	sorry, I've not gone back to xen-users since, got busy
14:49	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has joined #xen
14:49	<teferi>	well,
14:49	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 480 seconds]
14:49	<sdague>	Shaun: which post?
14:50	<Shaun>	titles xend laggggg
14:50	<sdague>	is that also xen3?
14:51	<Shaun>	yep
14:51	<sdague>	I know that a friend of mine was seeing really bad dom0 lagging on old xen2 after a bunch of days of uptime
14:52	<sdague>	yeh, no ideas there, but it is a pretty interesting use case
14:52	<sdague>	I know that PAE hasn't been tested quite as much as 32bit or 64bit
14:53	<Shaun>	sdague: yea, heard that, thought it was weird...
14:53	<Shaun>	seams like PAE would be more popular
14:53	<sdague>	it is, hopefully others will look into it
14:53	<Shaun>	ok dom0 shows only 1 cpu
14:53	<teferi>	so no conclusive answer for my cpu question?
14:53	<Shaun>	started 40 test guests... all using cpu 0 still
14:54	<sdague>	Shaun: what does your grub.conf/menu.lst look like?
14:54	<sdague>	feel free to priv msg me
14:54	<sdague>	teferi: there is no definitive answer for your question
14:55	<sdague>	if you are io intensive, dom0 will need a lot of cpu to get the job done, and having dedicated cpu to it will help
14:55	<sdague>	if you are cpu intensive, it's best to spread things around as much as possible
14:57	<Shaun>	sdague: http://pastebin.com/569091
14:59	<Shaun>	sdague: thanks for taking the time to help me out here, really appreciate it..
15:02	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
15:02	<Shaun>	xm vcpu-list only takes about 15 seconds when maxcpus=1 and 40 guests are running..
15:02	<Shaun>	:)
15:03	<sdague>	Shaun: remove maxcpus=1 from the xen line
15:03	<sdague>	i.e. the kernel stanza
15:03	<Shaun>	whoops
15:03	<sdague>	it should only be on the module stanza for dom0-
15:03	<Shaun>	sorry that was left from testing
15:05	<Shaun>	one sec let me give it a reboot
15:07	<Shaun>	for i in `seq 1 40`;do xm shutdown vps$i;done is taking about 800 years :)
15:07	<hensema>	what kind of hardware do you need to run 40 guests? 16 GB ram?
15:08	\|-\|	donour [donour@spruance.cs.unm.edu] has quit [Quit: Leaving.]
15:08	<Shaun>	hensema: Dual Xeon 3Ghz's, 8GB ram, 3ware 9550 SATA II controller with 6 300GB drives in a raid 10 config...
15:09	<Shaun>	[root@localhost testing][root@localhost testing]# ps auxf\|grep xend\|wc -l
15:09	<Shaun>	107
15:09	<hensema>	hmmm nice
15:09	<hensema>	nothing too wild
15:09	<Shaun>	hensema: probably guy dual cores next time..
15:13	[~]	hensema 's probably going to start off slowly with a single core opteron w/ 2 GB ram and sata raid-1
15:14	<Shaun>	sdague: well dom0 still shows 4 cpu's
15:14	<Shaun>	but i just noticed that three of them are in a p state..
15:15	<Shaun>	http://pastebin.com/569109
15:15	\|-\|	xenic [~xenic@TLV62-0-120-25.bb.netvision.net.il] has quit [Quit: Leaving]
15:16	<sdague>	hmmm.. odd
15:16	<sdague>	what is dom0-cpu set to in the xend config
15:17	<sdague>	oh, wait
15:17	<sdague>	that is just an artifact of vcpu-list
15:17	<sdague>	xm list will show dom0 on only 1 cpu
15:18	<Shaun>	yes, xm list shows dom0 vcpus = 1
15:19	<sdague>	yeh, so you're only on 1 cpu now
15:19	<Shaun>	hmm, ok
15:19	<sdague>	rharper: why does vcpu-list work like that again?
15:19	<sdague>	I know there was a reason
15:19	<Shaun>	makes sence i guess
15:20	<Shaun>	http://pastebin.com/569116\
15:20	<Shaun>	http://pastebin.com/569116
15:20	<Shaun>	guests are still only being set to cpu's 1 and 3
15:20	<Shaun>	this is because those are real cpu's you say?
15:20	<Shaun>	seams like 0 and 2 would be real and 1 3 would be ht
15:21	<sdague>	well, think of it being 2 ht in 1 cpu
15:21	<sdague>	it's not that one is a real cpu and one is a hyperthread, it's just 2 in one cpu
15:22	<Shaun>	right.
15:22	<sdague>	so as long as you only use 1 you won't get all those problems with coliding caches
15:22	<Shaun>	oh
15:22	<Shaun>	so only use 1 ht per cpu...
15:22	<sdague>	and from experience, the cambridge team found that dom0 actually works really well on a dedicated hyperthread (it doesn't need dedicated cpu)
15:23	<sdague>	so the default allocator just does that for you
15:23	<sdague>	hence dom0 on 0, domUs on 1 & 3
15:23	<Shaun>	right, but now dom0 is on cpu0(ht1) and a few guests are on cpu0(ht2) right?
15:24	<sdague>	yes, but that isn't bad for performance
15:24	<sdague>	it is actually pretty good as long as you aren't running cpu intensive loads in dom0
15:24	<Shaun>	ok, but it would be bad if i set guests to use cpu 2?
15:25	<Shaun>	most will probably be IO but their will be a fair amount of cpu also..
15:25	<Shaun>	40 or so guests running for customers...
15:25	\|-\|	kmacy [~kmacy@adsl-69-109-124-171.dsl.pltn13.pacbell.net] has joined #xen
15:25	<sdague>	yeh, then the domUs on cpu2 would actually be in the same core as the ones on cpu3, but sharing the same caches, so when they got scheduled they'd keep flushing each other's caches
15:25	<sdague>	which you'd see as a net loss in performance
15:26	<sdague>	Shaun: the cpu usage will be mostly in domUs though, except for the io handling in dom0
15:26	<sdague>	and the io handling works fine on a hyperthread
15:26	<sdague>	at least that's generally what has been seen
15:26	<Shaun>	ok
15:27	<Shaun>	sdague: ok then would it be a advantage to give dom0 2 vcpu's and give it one ht from each core?
15:27	<sdague>	I'm not sure
15:27	<sdague>	you could try and see if you had some typical load
15:28	<Shaun>	just the amount of time it takes for xm vcpu-list and xm list on a host like this with 40 IDLE guests running has me concerned...
15:29	<Shaun>	i'm just wondering how long it's going to take when say 40 guests are no longer idle... you know.
15:29	<sdague>	yeh, that seems od
15:29	<Shaun>	who should i be talking to about that?
15:29	<Shaun>	seams like a big problem.
15:30	<Shaun>	my backend scripts alone run xm list every 30 seconds to check on things.
15:44	<iamlost>	:)
15:44	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 480 seconds]
15:45	<iamlost>	gerrit: hi
15:45	<iamlost>	op
15:46	\|-\|	johnlev [~johnlev@nwkea-socks-1.sun.com] has quit [Quit: Leaving]
15:47	\|-\|	johnlev [~johnlev@nwkea-socks-1.sun.com] has joined #xen
15:48	<Shaun>	hmm, looks like with a xm vcpu-list xenstore hits the roof..
15:48	<Shaun>	cpu wise
15:54	<Shaun>	wow, now i have xenconsoled thrashing 99% cpu
15:56	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
15:56	<Shaun>	i have 2 guests running a while true;do echo blah;done
15:57	<Shaun>	so it would make sense i guess is a console was attached...
15:57	<Shaun>	but i guess xenconsoled is watching everything fly by?
16:01	\|-\|	jerone [~jerone@pixpat.austin.ibm.com] has quit [Quit: Leaving]
16:02	<Shaun>	looks like i need to hunt down Rusty Russell :)
16:02	<aliguori>	why?
16:02	<Shaun>	his name is at the top of xenstored_core.c
16:02	<aliguori>	oh
16:02	<Shaun>	assume he wrote it...
16:03	<aliguori>	rharper, any idea why xm vcpu-lits would cause xenstore cpu usage?
16:03	<Shaun>	aliguori: and your name is at the top of console daemon :)
16:03	<aliguori>	rharper, are you fetching every individual enable flag with a differen transaction?
16:04	<aliguori>	Shaun, i reckon the vcpu stuff may be unoptimized use of transaction... xenconsoled cpu usage is probably a bug
16:04	<Shaun>	aliguori: xm list does the same, it spikes xenstored for about 3 seconds though.
16:04	<aliguori>	probably a bad file descriptor
16:05	<Shaun>	aliguori: you want to take a peak? if you have time that is..
16:07	<aliguori>	uh
16:07	<aliguori>	i'm still trying to think of what the problem would be
16:07	<rharper>	aliguori: vcpu-list should require anything from the store
16:07	<Shaun>	aliguori: this is what a strace shows on xenconsoled... http://pastebin.com/569203
16:07	<rharper>	the only thing in the store vcpu related is the availability value which only changes via vcpu-set
16:07	<aliguori>	probably looping on select
16:07	<rharper>	and on domain creation
16:08	<Shaun>	rharper: with 40 domU's started xm vcpu-list takes about 15 seconds to run
16:08	<Shaun>	also causes xenstored to run 99% cpu
16:09	<aliguori>	Shaun, looks like you're writing a bunch of data to the console in two domains
16:09	<Shaun>	rharper: you may be interested to look at my post here too... http://lists.xensource.com/archives/html/xen-users/2006-02/msg00835.html
16:10	<Shaun>	aliguori: ya, i have 2 domains running a while true;do echo blah;done
16:10	<Shaun>	but no attached consoles
16:10	<aliguori>	well
16:10	<aliguori>	xenconsole buffers domain otuput
16:10	<aliguori>	so yeah
16:10	<aliguori>	it's gonna be eating up a bunch of cpu
16:10	<aliguori>	that's a given
16:11	<Shaun>	i see
16:11	<aliguori>	that's just the current architecture.. it would be better to move that buffering to domUs of course
16:11	<aliguori>	when i suggested that to Ian, he didn't seem to excited about it though
16:12	<Shaun>	it makes sence to me that it would do it if a console was attached, but i figured xenconsoled didnt have the pts open
16:12	<aliguori>	Shaun, yeah, that's how it should work, i agree, but it's not the way it's currently architected
16:12	<aliguori>	consoles ought to have large ring buffers in their own memory space
16:12	<aliguori>	instead of single page ones
16:13	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has quit [Quit: yay i have a custom quit message]
16:13	<aliguori>	but that's a pretty pervasive change that we really can't make right now
16:13	<aliguori>	maybe for 3.1
16:13	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has joined #xen
16:13	<Shaun>	aliguori: what has me concerned... is that alot of firewall scripts enable logging that goes through syslog and to the console... if i have say a few guests getting hit hard it could eat a ton of cpu
16:14	<aliguori>	Shaun, strictly speaking, not running xenconsoled won't do any harm to the system
16:14	<aliguori>	you just lose console output
16:14	<aliguori>	but xenconsoled needs to run if you want to use xm console
16:15	<Shaun>	right, i need console though :)
16:15	<aliguori>	yeah..
16:16	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
16:17	<Shaun>	aliguori: why is it buffering on a console that nobody is attached to?
16:17	<DV>	aliguori: it's just a daemon because we don't want to buffer in kernel, right ?
16:17	<aliguori>	DV: it's a daemon for historical reasons
16:17	<DV>	Shaun: probably to keep some history
16:18	<aliguori>	i mean, there was a time when it made sense
16:18	<aliguori>	it just doesn't really make sense anymore
16:18	<DV>	aliguori: so more code to kill :-)
16:18	<Shaun>	i see, it looks to dump the buffer each time you connect to it..
16:19	<aliguori>	DV: or just get rid of it all in favor of an actual framebuffer :-)
16:19	<aliguori>	which is what i think is the right solution O:-)
16:20	<DV>	aliguori: framebuffer ... I must be old, to me it mean graphic card video ram
16:20	<aliguori>	uh huh :-)
16:20	<aliguori>	virtual framebuffer
16:20	<aliguori>	http://wiki.xensource.com/xenwiki/VirtualFramebuffer
16:21	<DV>	oh, that, yes
16:21	[~]	DV hands an axe to Anthony
16:22	<DV>	have fun
16:22	<aliguori>	hehe
16:22	<aliguori>	the vcpu-list stuff is puzzling.. i suspect it's xend doing some weird stuff
16:23	<Shaun>	aliguori: was rharper the guy to talk to about it?
16:24	<aliguori>	yeah, it's not vcpu specific...
16:24	<aliguori>	i doubt it's xenstored's fault too
16:24	<aliguori>	transactions can be expensive with a large store
16:24	<aliguori>	40 domains will give you a decent size store
16:24	<Shaun>	whats considered large?
16:24	<aliguori>	so if xend is not using transactions efficiently, then it's possible that that's the problem
16:24	<aliguori>	but i'm not sure why vcpu-list would be the worst-case of that
16:24	<aliguori>	i'd have to look at the code
16:25	<aliguori>	open a bug in bugzilla, and the issue won't be forgotten atleast
16:29	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Ex-Chat]
16:35	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Read error: Operation timed out]
16:48	\|-\|	ivan [~ikelly@86.41.204.130] has quit [Quit: leaving]
16:49	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
17:00	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
17:14	<Shaun>	aliguori: took a look at the code, i dont know python enough to tell whats going on though... i opened a bug http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=545
17:38	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 480 seconds]
17:38	\|-\|	ivan [~ikelly@86.41.204.130] has joined #xen
17:39	\|-\|	ivan [~ikelly@86.41.204.130] has quit [Quit: ]
17:50	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
17:57	\|-\|	homebaum [~michael@pool-71-245-98-69.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
18:05	<teferi>	can anyone help me with getting a vnet set up?
18:05	<teferi>	I can't seem to build the vnet kernel module, for one thing
18:07	<sh0ck>	don't ask to ask. fpor example use pastebin.com
18:08	<teferi>	http://pastebin.com/569411 okay, here's the make output
18:09	<teferi>	and yes, /usr/src/linux does have xenified sources in that
18:09	\|-\|	pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has quit [Remote host closed the connection]
18:22	<tonyb>	teferi: Can you add a V=1 to the make command on line 1?
18:22	<teferi>	absolutely, hang on
18:23	[~]	tonyb hums gameshow style thinking music ...
18:24	<teferi>	okay, this one's gonna be long
18:24	<tonyb>	:)
18:25	<teferi>	http://pastebin.com/569432
18:26	<tonyb>	looking/reading ..... Your turn to hum :)
18:26	<teferi>	no hurry
18:27	<teferi>	you guys have been a great help, the least I can do is be patient
18:29	<teferi>	the warning on line 8 makes me nervous
18:29	<teferi>	let alone the actual build-stopping errors
18:30	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 481 seconds]
18:36	<tonyb>	Well the quickest solution would be to remove the word "inline" from the function delclaration on line 77 of tunnel.h
18:37	<tonyb>	but that's not really the right solution. .... I didn't know you can't nest recursive inline :(
18:39	<teferi>	it makes perfect sense
18:39	<teferi>	heh
18:40	<teferi>	well, it still doesn't build after doing that
18:40	[~]	teferi hacks some more
18:41	<teferi>	well, I got it to build
18:42	<teferi>	why on earth do the vnet tools use the Boehm GC?
18:43	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
18:44	<tonyb>	teferi: Hmm I just wrote a quick test program which does call a recursive inline. so I'm rathe confused
18:45	<teferi>	tonyb: well, I removed the inline and hacked a little, and it built
18:45	<teferi>	I'll see if it works
18:46	<teferi>	boo, it doesn't loda
18:46	<teferi>	...load
18:47	<teferi>	[WRN][WRN] VNET> vnet_init err=-1
18:47	<teferi>	[WRN][WRN] VNET> skb mac duff!
18:47	<teferi>	[WRN][WRN] VNET> skb mac duff!
18:47	<teferi>	[WRN][WRN] VNET< err=-1
18:47	<teferi>	talk about cryptic!
18:49	<tonyb>	yeah, cryptic is right
18:51	<teferi>	I have no idea where to go from here. it fails because vnet_init returns -1, but there are four different things that could be causing that
18:51	<teferi>	well, three likely things
18:58	\|-\|	anball [~anball@cpe-069-134-210-147.nc.res.rr.com] has quit [Quit: Leaving]
19:02	\|-\|	bestorga [~bestorga@129.33.1.37] has quit [Quit: Leaving]
19:23	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 480 seconds]
19:28	<teferi>	yow
19:28	<teferi>	I bludgeoned it into loading, and it wedged the system
19:28	<teferi>	that is one evil driver
19:36	\|-\|	gerrit [~gerrit@129.33.1.37] has joined #xen
19:42	\|-\|	ns [~niv@129.33.1.37] has quit [Quit: Leaving]
19:45	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
19:55	<teferi>	so, any insights into my vnet problem, anyone??
19:59	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Read error: Connection reset by peer]
20:22	\|-\|	gerrit [~gerrit@129.33.1.37] has quit [Ping timeout: 481 seconds]
20:55	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has quit [Quit: Leaving]
20:58	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
21:00	<teferi>	sigh.
21:07	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has joined #xen
21:09	<tonyb>	teferi: nup sorry.
21:09	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has quit [Quit: ]
21:10	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
21:12	\|-\|	movement changed nick to conbot
21:13	\|-\|	conbot changed nick to movement
21:15	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
22:23	\|-\|	riel [riel@fangorn.surriel.com] has quit [Remote host closed the connection]
22:25	\|-\|	surriel [riel@fangorn.surriel.com] has joined #xen
22:47	\|-\|	kmacy [~kmacy@adsl-69-109-124-171.dsl.pltn13.pacbell.net] has quit [Remote host closed the connection]
22:56	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has left #xen [Rotating Logs]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has joined #xen
23:02	\|-\|	ronpoz [~ronpoz@ool-182e6376.dyn.optonline.net] has joined #xen
23:05	\|-\|	ronpoz [~ronpoz@ool-182e6376.dyn.optonline.net] has left #xen []
---	Log	closed Fri Feb 24 00:00:10 2006