1354580250 Q * nkukard Read error: Connection reset by peer
1354580572 J * nkukard ~nkukard@41-133-139-74.dsl.mweb.co.za
1354582319 N * Bertl_zZ Bertl
1354582324 M * Bertl back now ...
1354583430 Q * Ghislain Quit: Leaving.
1354583817 J * Ghislain ~aqueos@adsl1.aqueos.com
1354584223 Q * Ghislain Quit: Leaving.
1354585568 J * clopez ~clopez@242.17.60.213.dynamic.mundo-r.com
1354592725 Q * clopez Ping timeout: 480 seconds
1354595289 M * Bertl off to bed now ... have a good one everyone!
1354595294 N * Bertl Bertl_zZ
1354598051 Q * lkosewsk Ping timeout: 480 seconds
1354607515 Q * geos_one Quit: ChatZilla 0.9.89 [Firefox 16.0.2/20121029000647]
1354608091 J * Ghislain ~aqueos@adsl1.aqueos.com
1354610742 N * Bertl_zZ Bertl
1354610747 M * Bertl morning folks!
1354611927 J * fleischergesell ~fleischer@p4FDF025A.dip.t-dialin.net
1354611970 M * Ghislain hello
1354612048 M * fleischergesell Gday folks, I understand that memory alloation is purely host-baed, so I'd presume there is no benefit in limiting the swap space in a given guest using cgroups, or is there?
1354612099 M * Bertl depends on what your goal is, if you want to keep a guest from swapping out memory, a swap limit is a good choice
1354612183 M * fleischergesell so the host's descisions whether to swap pages or not are in fact based on the actual cgroup configuration for a guest?
1354612244 M * Bertl sure, that's the purpose of those cgroup subsystems
1354612283 M * fleischergesell would that mean, if I do not add a memsw.limit, a guest will never use swap?
1354612314 M * fleischergesell (of course I already have memory.limit in place)
1354612351 M * Bertl IIRC, the default is unlimited
1354612408 M * fleischergesell So I guess what I see from top, htop etc. is just bogus?
1354612427 M * fleischergesell + in a given guest with just memory.limit_in_bytes set
1354612428 M * Bertl don't know what you're seeing there :)
1354612434 M * fleischergesell well, no swap then
1354612451 M * fleischergesell to be precise: no usable swap, as if no swap had been mounted
1354612490 M * Bertl what kernel, what cgroup subsystems, what util-vserver version?
1354612618 Q * ensc|w Remote host closed the connection
1354612627 J * ensc|w ~ensc@www.sigma-chemnitz.de
1354612643 M * fleischergesell kernel 3.2.4, vserver on /dev/cgroup type cgroup (rw,cpuset,cpu,cpuacct,memory,devices,freezer,net_cls), util-vserver-0.30.216-pre3037
1354612687 M * Bertl so the swap cgroup is not mounted
1354612728 M * fleischergesell but why do we get to see "swap" space in a guest once we allocate both memory and memsw cgroup lmits?
1354612767 M * fleischergesell but thanks for the hint, I thought swap was a subset of memory :/
1354612854 M * Bertl hmm, give me a sec, I think you're right
1354612944 M * Bertl yes, so the question is, is there /dev/cgroup/<guest>/memory.memsw*
1354612974 M * fleischergesell sure
1354613000 M * fleischergesell There is, for any given guest, even those that have no individual cgroups configured
1354613046 J * isAAAc ~isaaac@37.160.39.53
1354613069 M * Bertl okay, so the controller is there and active, what about the actual values, e.g. memory.memsw.limit_in_bytes ?
1354613123 M * fleischergesell for a guest where we configured both values, both a correct (e.g. 10 for memory.limit and 12 for memory.memsw) which results in 2GB available swap space inside the guest
1354613157 M * Bertl and 2GB are shown inside I presume?
1354613162 M * fleischergesell correct
1354613180 M * fleischergesell once I delete the memory.memsw configuration from  that guest, we fall back to no swap shown in guest
1354613182 M * Bertl okay, and for the 'disabled' ones?
1354613197 M * Bertl i.e. what does it show/contain there?
1354613207 M * fleischergesell although the memory.memsw.limit_in_bytes then outputs something like max-int or so
1354613247 M * Bertl okay, so that's most likely a bug in the memory/swap info virtualization then
1354613258 M * fleischergesell so I suspect that the number ist just too high to be shown :/
1354613258 M * Bertl could you test this with a recent kernel?
1354613292 M * Bertl nah, the max-int like value is handled special
1354613311 M * fleischergesell Not on this particular system, but I will try this week on another one to see whether this differs
1354613318 M * fleischergesell this = the behaviour
1354613390 M * fleischergesell do you think its just visualisation problems or might the actual swapping also be affected?
1354613407 M * Bertl okay, thanks, please keep me updated on this, as I said, I suspect a small problem with the virtualization
1354613439 M * Bertl the limit will work as intended (i.e. unlimited swap up to the max host swap space)
1354613479 M * Bertl but the visual representation of this state is probably wrong
1354613490 M * fleischergesell Thats good, I'll test with a more recent kernel and let you know about the results
1354613512 M * Bertl thanks! appreciated!
1354613522 M * fleischergesell By the way, is there any "easy" way to debug vcontext segfaults?
1354613538 M * Bertl vcontext should never segfault :)
1354613540 M * fleischergesell We have some of them showing up every now and then
1354613547 M * fleischergesell like 1-2 a week or so
1354613557 M * Bertl do you get a kernel stack trace?
1354613562 M * fleischergesell no
1354613569 M * fleischergesell thats what we find weird
1354613578 M * fleischergesell and there is nothing indicating a process crash
1354613588 M * Bertl okay, so how do you know that it is vcontext?
1354613589 M * fleischergesell in fact, we do not even know which guest is affected by this
1354613598 M * fleischergesell well, dmesg tells us
1354613607 P * fr00d 
1354613664 M * Bertl you could try to enable core dumping at least for the host
1354613673 M * Bertl (or the caller of vcontext)
1354613724 M * fleischergesell whoever that might be - will enable core dumps on the host and wait for the next segfault to happen
1354613735 M * fleischergesell just in case you can get anything from it: vcontext[15395]: segfault at 7fffbfb44ff8 ip 0000000000403a8e sp 00007fffbfb45000 error 6 in vcontext[400000+9000]
1354613916 M * fleischergesell address differs almost always, ip sometimes matches, sp always differs and it is always 6 in vcontext[400000+9000]
1354613935 M * fleischergesell maybe that tells you something
1354614412 M * Bertl 6 means ENXIO
1354614503 M * fleischergesell what does that mean in the context of vcontext?
1354614520 M * Bertl it's the last error code reported by a syscall IIRC
1354614555 Q * isAAAc Ping timeout: 480 seconds
1354614610 M * Bertl 7fffbfb44ff8 (or whatever you get there) is the address causing the segfault
1354614629 M * Bertl and 0000000000403a8e is the address of the code causing the bad access
1354614678 M * Bertl so you could probably load vcontext with gdb (given that you have debug symbols) and check that location
1354614717 M * fleischergesell I guess we will have to do this then
1354614748 M * fleischergesell if only we could reproduce the error by hand, we could just test on different kernel-versions
1354614816 M * Bertl segfaults are usually userspace problems not kernel issues
1354614841 M * Bertl i.e. something goes wrong in vcontext code or in a library it uses
1354614857 M * fleischergesell so this is likely to sit in util-vserver or the libraries it uses?
1354614882 M * daniel_hozac from the address, i'd guess dietlibc.
1354614883 M * Bertl yup
1354614983 M * fleischergesell could you guess any method to trigger the segfault?
1354615027 M * fleischergesell Then we could change e.g. dietlibc versions to see if that helps
1354615066 M * daniel_hozac what util-vserver version are you using?
1354615083 M * fleischergesell util-vserver-0.30.216-pre3037
1354615142 M * fleischergesell we use dietlibc-dev 0.32-5.1 
1354615885 J * kir ~kir@swsoft-msk-nat.sw.ru
1354616965 P * kir PING 1354616965
1354617249 J * BenG ~bengreen@cpc29-aztw23-2-0-cust144.18-1.cable.virginmedia.com
1354617635 J * clopez ~clopez@242.17.60.213.dynamic.mundo-r.com
1354621200 Q * ircuser-1 Ping timeout: 480 seconds
1354623377 J * fisted_ ~fisted@xdsl-87-78-232-156.netcologne.de
1354623586 Q * fisted Read error: No route to host
1354623588 N * fisted_ fisted
1354624663 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1354627046 Q * BenG Quit: I Leave
1354631305 Q * nkukard Ping timeout: 480 seconds
1354631956 J * nkukard ~nkukard@41-133-139-74.dsl.mweb.co.za
1354634125 M * Bertl off for a nap ... bbl
1354634149 N * Bertl Bertl_zZ
1354635161 P * fleischergesell 
1354636277 N * ensc Guest473
1354636287 J * ensc ~irc-ensc@p54ADECA2.dip.t-dialin.net
1354636693 Q * Guest473 Ping timeout: 480 seconds
1354637577 Q * ircuser-1 Remote host closed the connection
1354639881 Q * Ghislain Quit: Leaving.
1354640108 J * geos_one ~chatzilla@80.123.185.198
1354640800 J * bonbons ~bonbons@2001:960:7ab:0:9c4d:3fde:c54e:e396
1354641605 Q * Defaultti Quit: Quitting.
1354641657 J * Defaultti defaultti@lakka.kapsi.fi
1354644474 N * Bertl_zZ Bertl
1354644477 M * Bertl back now ...
1354645676 Q * hparker Remote host closed the connection
1354646193 J * Ghislain ~aqueos@adsl1.aqueos.com
1354646335 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1354648642 Q * DoberMann Quit: ajout de disque express
1354650988 J * DoberMann ~james@2a01:e35:8b44:84c0::2
1354654610 J * benl ~benl@dockoffice.sonassihosting.com
1354654675 M * benl Hey Bertl - any chance of a private chat?
1354655599 M * Bertl sure
1354656415 Q * micah Quit: leaving
1354656418 J * micah ~micah@199.254.238.47
1354658253 J * Ghislain1 ~aqueos@adsl1.aqueos.com
1354658253 Q * Ghislain Read error: Connection reset by peer
1354658604 Q * bonbons Quit: Leaving
1354658698 Q * Ghislain1 Quit: Leaving.
1354658993 Q * benl Quit:  I love my HydraIRC -> http://www.hydrairc.com <-
1354659306 J * imcsk8 ~ichavero@148.229.1.11