1268440742 Q * ntrs_ Ping timeout: 480 seconds
1268441077 Q * dowdle Remote host closed the connection
1268441730 Q * thierryp Remote host closed the connection
1268443963 M * Bertl off to bed now ... have a good one everyone!
1268443972 N * Bertl Bertl_zZ
1268444249 M * Medivh .dupe mp3 michael morgan
1268444287 M * Medivh whops, that wasnt exactly supposed to go here :D
1268444394 M * Medivh (and no worries, i do actually _buy_ my music ;))
1268444725 P * _mart Leaving
1268449240 J * derjohn_foo ~aj@e180192075.adsl.alicedsl.de
1268449672 Q * derjohn_mob Ping timeout: 480 seconds
1268451469 Q * derjohn_foo Ping timeout: 480 seconds
1268452827 J * SauLus_ ~SauLus@c207234.adsl.hansenet.de
1268453237 Q * SauLus Ping timeout: 480 seconds
1268453237 N * SauLus_ SauLus
1268454407 J * petzsch ~markus@dslb-094-222-076-130.pools.arcor-ip.net
1268457317 Q * petzsch Quit: Leaving.
1268458087 J * petzsch ~markus@dslb-094-222-076-130.pools.arcor-ip.net
1268459247 Q * petzsch Quit: Leaving.
1268460845 N * DoberMann DoberMann[ZZZzzz]
1268464567 J * ghislain ~AQUEOS@adsl2.aqueos.com
1268467915 J * thierryp ~thierry@home.parmentelat.net
1268467935 J * derjohn_mob ~aj@e180193135.adsl.alicedsl.de
1268469740 J * ntrs ~ntrs@77.29.6.64
1268470924 M * harry biz: lol... i saw the updated patch, so i immediately fixed it :)
1268471246 M * harry Bertl_zZ: will you be keeping support up for 2.6.32 kernels?
1268471279 Q * thierryp Ping timeout: 480 seconds
1268472571 J * ntrs_ ~ntrs@77.28.25.194
1268472682 J * ntrs__ ~ntrs@77.29.6.64
1268472990 Q * ntrs Ping timeout: 480 seconds
1268473112 Q * ntrs_ Ping timeout: 480 seconds
1268473821 J * derjohn ~derjohn@80.69.41.3
1268474007 J * mtg ~mtg@port-87-193-189-26.static.qsc.de
1268478989 J * ghislain1 ~AQUEOS@adsl2.aqueos.com
1268479237 Q * ghislain Ping timeout: 480 seconds
1268480583 J * ntrs_ ~ntrs@77.28.25.194
1268480686 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1268481025 Q * ntrs__ Ping timeout: 480 seconds
1268483452 J * ntrs__ ~ntrs@77.28.43.1
1268483882 Q * ntrs_ Ping timeout: 480 seconds
1268486087 J * hijacker ~hijacker@87-126-142-51.btc-net.bg
1268487865 N * Bertl_zZ Bertl
1268487872 M * Bertl morning folks!
1268487889 M * Bertl harry: most likely for as long as they are maintained upstream
1268488334 M * Bertl arekm: might it be that you have VIRT_MEM enabled but no cgroup/rss limit applied
1268490195 J * BenG ~bengreen@cpc2-aztw22-2-0-cust521.aztw.cable.virginmedia.com
1268490233 Q * BenG 
1268492406 M * Bertl off for now .. bbl
1268492411 N * Bertl Bertl_oO
1268492884 M * theocrit1 1
1268492889 N * theocrit1 theocrite
1268494280 M * arekm Bertl_oO: yes, virt_mem is enabled, cgroups limit not applied
1268496802 N * Bertl_oO Bertl
1268496823 M * Bertl arekm: well, there you go, the free is calculated as total - used
1268496842 M * arekm Bertl: so a bug 
1268496843 M * arekm ;P
1268496848 M * Bertl so you natrually end up with free = total, disable virt_mem if you don't want that
1268496857 M * arekm Bertl: could it work as before if limits not set?
1268496879 M * Bertl actually it does, if you don't use memory cgroups
1268496883 M * arekm Bertl: I want memory accounting per guest in guest
1268496894 M * arekm Bertl: I don't use but have these enabled in kernel
1268496903 M * Bertl that's your problem
1268496906 M * arekm and I cannot disable because someone might use these
1268496930 M * Bertl what's the point in setting VIRT_MEM with no limits/accounting?
1268496971 M * arekm hm, previous kernels did proper accounting in such case
1268496980 M * arekm so why do you say "no accounting" ?
1268497004 M * Bertl we are switching to cgroups, so, if you want accounting, you need to use that framework in the future
1268497021 M * Bertl for the time being, if cgroups are disabled, the virtmem will use the 'old' accounting
1268497052 M * arekm but cgroups ARE disabled. cgroups need configuration first. if not configured then it work in a old way in generic kernel
1268497081 M * Bertl no, they aren't disabled in the kernel
1268497115 M * Bertl not sure what we'll do in the future with the 'old' rss accounting, but I presume we'll make it an option which defaults to no
1268497128 M * arekm but if you take vanilla kernel, enable cgroup in config (but not configure at runtime) then such generic kernel behaves exactly as if cgroup is disabled in config
1268497146 M * Bertl no, sorry, it doesn't
1268497157 M * arekm ouh
1268497162 M * arekm what changes then?
1268497177 M * arekm because I didn't notice any difference :)
1268497179 M * Bertl there is an init cgroup by default, which is used for all processes
1268497208 M * arekm right but from user point of view there is no change at all
1268497224 M * Bertl performance is worse (from user point of view)
1268497226 M * arekm like it doesn't lie about free space for example
1268497233 M * arekm free mem
1268497239 M * Bertl the guest doesn't lie about that either
1268497252 M * arekm it tells me that I don't use any memory
1268497259 M * arekm which is lie isn't it?
1268497278 M * Bertl we'll as you do not do any accounting for the guest, no memory is used (for the guest)
1268497297 M * arekm so there is big behaviour change 
1268497319 M * Bertl yes, as we are moving from rss accounting to cgroups (in an experimental branch :)
1268497352 M * Bertl but I'm open to suggestions how to 'improve' on the user experience :)
1268497363 M * arekm could it use some own default "init cgroup" per guest so accounting would work by default?
1268497373 M * Bertl (for the cases where folks use VIRT_MEM without guest memory accounting)
1268497400 M * Bertl arekm: nope, that would be against our rule to keep it simple and modular
1268497414 M * arekm Anyway how to turn that cgroup accounting?
1268497419 M * Bertl we do not force the user to use a rather heavy accounting
1268497449 M * Bertl http://linux-vserver.org/util-vserver:Cgroups
1268497470 M * Bertl skim down to the memory accounting
1268497515 M * arekm hm, there is no word "accounting" in that doc
1268497538 M * Bertl using cgroup to enforce memory limits
1268497619 M * arekm oh crap, this requires filling "how much ram we have here" data for every guest and keeping that in sync with real hw
1268497639 M * arekm will try anyway
1268497648 M * Bertl once again, why not simply remove the VIRT_MEM in your case?
1268497765 M * arekm I just did that but not no one will know from inside of guest how much memory is eaten by that guest
1268497808 M * Bertl so, you want to be able to see what is used _inside_ but you don't want it reported by /proc/meminfo or what?
1268497912 M * arekm want old behaviour but now I'm not sure if old behaviour is what I was thinking it is
1268497937 M * arekm is old behaviour "accounting of used memory per guest if no rss limits set" ?
1268497945 M * Bertl hehe, okay, let's forget about the 'old' behaviour for a moment, and consider future behaviour then
1268497977 M * Bertl the 'old' behaviour can be broken down into two parts/mechanisms
1268498004 M * Bertl rss accounting (which is done unconditionally) and virtual memory display (which you enable with virt_mem)
1268498026 M * Bertl the main problem always was and still is, that the kernel does not report the 'used' memory, just the total and free
1268498200 M * Bertl now, for the interim time, we still have rss accounting done as before, but also the kernel compile time option to select the cgroup memory controller
1268498236 M * Bertl the virt_mem is basically unchanged for the non-cgroup case, and uses the cgroup interface when compiled with cgroups
1268498270 M * Bertl one difference, and that one is most likely the one which causes what you currently observe
1268498296 M * Bertl is that the new virt_mem also shows the cached value instead of 0
1268498362 M * Bertl (I presume if you comment that part out, your 'old' behaviour will be there despite the fact that you switched to cgroups)
1268498406 M * Bertl kernel/vserver/limit.c ~363 in vx_vsi_cached()
1268498426 M * Bertl just replace the return mem_cgroup_stat_read_cache(mcg); with
1268498432 M * Bertl return 0;
1268498463 M * Bertl this will report the cached memory as 0 (as we did before in 2.6.31, not recent 2.6.32 or 33 though)
1268498698 Q * mtg Quit: Verlassend
1268498941 M * Bertl okay, off for dinner ... bbl
1268498947 N * Bertl Bertl_oO
1268500966 N * Bertl_oO Bertl
1268501272 M * Bertl back now ...
1268502022 Q * MeCooL Ping timeout: 480 seconds
1268502500 J * sur5r sur5r@courante.etherkiller.de
1268507144 M * geb Bertl, http://paste.linux-vserver.org/14813
1268507191 M * geb i guess that's not important, just in case you are interested
1268507209 M * geb (debian kernel source, maybe there is some local patch that caused the problem)
1268507242 M * Bertl probably more interesing for the debian maintainers atm (i.e. micah & co)
1268507298 M * Bertl but I'd try to apply with -l, as I do not see any difference in the reject
1268507671 M * geb cat patch | patch -p1 -l ?
1268507701 M * Bertl yep
1268507929 M * geb same result
1268507962 M * Bertl then you did something wrong
1268507993 M * Bertl the commoncap.c.rej file you pasted doesn't show any difference between source and destination
1268508016 M * Bertl anyway, try to make your patch output unified reject files (which are better readable)
1268508161 M * geb sorry, i am not very used with patch, how -u ?
1268508174 M * geb will check another time
1268508199 M * Bertl no idea what option your patch needs to write unified rejects
1268508255 M * Bertl it is -U or --unified-reject-files here
1268508337 Q * theocrite Quit: Lost terminal
1268508364 J * theocrite ~Hubert@kim.theocrite.org
1268508818 M * geb http://paste.linux-vserver.org/14814
1268508940 M * geb i just tested a few day ago on a different box (with a different version of the debian source package, 2.6.32-5 ), as this one is 2.6.32-9 maybe something has change on ...
1268508978 M * geb patch version is also different, 2.6 vs 2.5.9, but i don't think it changes much things
1268509271 M * Bertl so that reject can be ignored, as it just adds a newline
1268509307 M * Bertl no idea why the debian folks would add/remove an empty line, but that is what happened :)
1268509537 M * geb 'k thanks :)
1268509541 M * Bertl actually, it is me adding that empty line, so please ignore it *G*
1268509549 M * geb hehe :)
1268509561 M * Bertl i.e. thanks for spotting that useless hunk, will be removed in the next patch
1268509638 M * geb but, it works with 2.6.32-5 (testing version) and not 2.6.32-9 (unstable one) should i try to keep micah in touch ?
1268509663 M * Bertl nah, just ignore it for now, the issue will be gone in the next 2.6.32 patch anyways
1268509675 M * geb k :)
1268509711 M * geb will you also include the delta for uml ?
1268509743 M * Bertl that is already included here in my tree, so no worries there
1268509756 M * geb hehe :)
1268510184 J * thierryp ~thierry@home.parmentelat.net
1268511646 Q * ghislain1 Quit: Leaving.
1268513408 J * BenG ~bengreen@cpc2-aztw22-2-0-cust521.aztw.cable.virginmedia.com
1268514159 Q * BenG Quit: I Leave
1268514437 M * Bertl off to bed now .. have a good one everyone!
1268514444 N * Bertl Bertl_zZ
1268514466 Q * manana Ping timeout: 480 seconds
1268515633 Q * thierryp Remote host closed the connection
1268515653 J * thierryp ~thierry@home.parmentelat.net
1268516142 Q * thierryp Ping timeout: 480 seconds
1268516456 Q * hijacker Quit: Leaving
1268517706 Q * bonbons Quit: Leaving
1268518004 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1268520067 Q * ntrs__ Ping timeout: 480 seconds
1268521634 Q * bonbons Quit: Leaving
1268522911 J * manana ~mayday090@ns2.vsev.lanck.net
1268523602 J * mindo ~mindo@122-62-16-132.jetstream.xtra.co.nz
1268523952 Q * manana Ping timeout: 480 seconds