1330905610 J * kendy ~kendy@1RDAADJK6.tor-irc.dnsbl.oftc.net
1330905946 P * kendy 
1330906156 N * Bertl_zZ Bertl
1330906162 M * Bertl back now ...
1330910379 Q * micah Quit: leaving
1330911140 J * micah ~micah@micah.riseup.net
1330913107 Q * jeroen__ Ping timeout: 480 seconds
1330913395 J * jeroen__ ~jeroen@095-097-051-172.static.chello.nl
1330913714 J * notau ~notau@14-201-81-158.static.tpgi.com.au
1330914647 Q * jeroen__ Ping timeout: 480 seconds
1330916916 J * jeroen__ ~jeroen@095-097-051-172.static.chello.nl
1330919556 Q * kshannon Ping timeout: 480 seconds
1330919768 J * kshannon ~kris@122.252.14.166
1330928486 Q * notau Quit: Computer has gone to sleep.
1330929745 J * ghislain ~AQUEOS@adsl2.aqueos.com
1330930132 J * notau ~notau@14-201-81-158.static.tpgi.com.au
1330933734 J * ncopa ~ncopa@3.203.202.84.customer.cdi.no
1330935687 Q * notau Quit: Computer has gone to sleep.
1330935903 J * notau ~notau@14-201-81-158.static.tpgi.com.au
1330936094 Q * ensc|w Remote host closed the connection
1330936103 J * ensc|w ~ensc@www.sigma-chemnitz.de
1330936772 Q * notau Quit: Computer has gone to sleep.
1330937037 J * lucrus ~papo@dynamic-adsl-84-223-100-217.clienti.tiscali.it
1330937071 Q * lucrus 
1330938430 J * petzsch ~markus@dslb-092-078-115-163.pools.arcor-ip.net
1330939049 Q * Romster Quit: Geeks shall inherit properties and methods of object earth.
1330941492 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1330942138 Q * petzsch Quit: Leaving.
1330944656 J * clopez ~clopez@155.99.117.91.static.mundo-r.com
1330944725 M * Bertl off for now ... bbl
1330944729 N * Bertl Bertl_oO
1330946485 J * notau ~notau@gw-1.mel1.paranode.id.au
1330947656 Q * Esmil Quit: leaving
1330949175 Q * notau Quit: Computer has gone to sleep.
1330949357 J * notau ~notau@gw-1.mel1.paranode.id.au
1330949369 Q * Aiken Remote host closed the connection
1330949702 M * karasz hello
1330949914 N * monrad monrad-51468
1330950121 M * karasz i am a bit baffled by the fact that older documentation(even the great flower page) talks about /dev/cgroup but new uti-vserver seems to expect /sys/fs/cgroup
1330950203 M * karasz and what it is even more baffling (perhaps only for me) is that mkdir -p /sys/fs/cgroups/cpuset fails
1330950212 M * karasz "mkdir: cannot create directory `/sys/fs/cgroup/cpuset': No such file or directory "
1330950226 M * daniel_hozac /sys/fs/cgroup is only used on systems that use it.
1330950274 M * karasz so proper mode woul dbe to mount cgroup fs to /sys/fs/cgroup and only then use util-vserver?
1330950296 J * kir ~kir@swsoft-msk-nat.sw.ru
1330950356 M * daniel_hozac no, the proper usage would be to stick with /dev/cgroup, if your system isn't already using /sys/fs/cgroup
1330950366 M * karasz ic
1330950446 P * kir 
1330952862 Q * Enoria Ping timeout: 480 seconds
1330955518 Q * notau Quit: Computer has gone to sleep.
1330955858 J * notau ~notau@gw-1.mel1.paranode.id.au
1330955908 M * Bertl_oO off for a nap .. bbl
1330955915 N * Bertl_oO Bertl_zZ
1330961522 N * ensc Guest5152
1330961532 J * ensc ~irc-ensc@p54ADE535.dip.t-dialin.net
1330961643 J * petzsch ~markus@dslb-092-078-115-163.pools.arcor-ip.net
1330961877 Q * notau Quit: Computer has gone to sleep.
1330961943 Q * Guest5152 Ping timeout: 480 seconds
1330961960 J * hparker ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1330963238 J * dowdle ~dowdle@scott.coe.montana.edu
1330963371 J * notau ~notau@gw-1.mel1.paranode.id.au
1330963803 Q * ncopa Quit: Leaving
1330964317 N * Bertl_zZ Bertl
1330964322 M * Bertl back now ...
1330964731 P * petzsch 
1330967235 J * bonbons ~bonbons@2001:960:7ab:0:893a:cda0:f8d:f6d7
1330970709 M * clopez is there any drawbacks, problems or things to consider if I set "vm.overcommit_memory = 1" on a server that has some vservers running with memory limits configured with vlimit (VIRT_MEM flag) ?
1330970824 M * Bertl overcommit_memory = 1 is the more permissive mode than 0, which is the default
1330970872 M * Bertl i.e. 1 means, never check
1330970916 M * clopez yes.. but how this affects a vserver with memory limits? can this vserver use more memory than his own limits?
1330970919 M * clopez Since 2.1.27 there are a sysctl VM_OVERCOMMIT_MEMORY and proc file /proc/sys/vm/overcommit_memory with values 1: do overcommit, and 0 (default): don't.
1330970961 M * Bertl 2 is 'do not overcommit'
1330970963 M * clopez Since 2.5.30 the values are: 0 (default): as before: guess about how much overcommitment is reasonable, 1: never refuse any malloc(), 2: be precise about the overcommit - never commit a virtual address space larger than swap space plus a fraction overcommit_ratio of the physical memory.
1330970972 M * clopez copied from here http://www.win.tue.nl/~aeb/linux/lk/lk-9.html
1330970986 M * Bertl yep, that's what all current kernels use
1330971045 M * clopez so with a value of 1 (never refuse any malloc()) can cause any problem or unexpected situation if a server that has memory limits tries to use more memory than his limits¿?
1330971081 M * Bertl do you know what overcommitting memory means?
1330971180 M * clopez I understand that means that the kernel allows a process to allocate more memory than the one that the kernel can guarantee. If this process don't uses this memory all is fine but if he uses it an OOM situation will happen
1330971227 M * clopez I am wrong?
1330971241 M * Bertl correct, so with oc=1, malloc(16G) returns an address, even if the guest or the system (host) is limited to 8G
1330971272 M * Bertl with 0, it might return an error if the heuristics think that is too much over the top
1330971288 M * Bertl with oc=2 malloc _will_ return an error
1330971310 M * Bertl all 3 settings are completely independant from OOM killing
1330971342 M * clopez yes... so with oc=1, if this process starts to fill the 16GB of memory that he got allocated... what happens when it reachs the vserver limit of 8GB?
1330971363 M * Bertl the same as with oc=0, OOM killer will strike
1330971433 M * clopez but only for the process on the context of this guest, is that right?
1330971449 M * Bertl depends on the actual host limits
1330971473 M * Bertl if the host gets into an OOM situation, it can kill anything not protected
1330971483 M * Bertl and if nothing can be killed it will panic
1330971498 M * clopez yes, supposing that the host still has memory available
1330971504 M * clopez only the limits of the guest were triggered
1330971556 M * Bertl then only guest processes should be affected
1330971584 M * clopez nice
1330971590 M * clopez thanks for the clarification :)
1330971606 M * Bertl no problem
1330971903 M * Bertl off for now ... bbl
1330971908 N * Bertl Bertl_oO
1330979332 J * hijacker_ ~hijacker@cable-84-43-136-96.mnet.bg
1330979977 Q * notau Quit: Textual IRC Client: http://www.textualapp.com/
1330980541 Q * cuba33ci Read error: Connection reset by peer
1330980590 J * cuba33ci ~cuba33ci@114-36-241-156.dynamic.hinet.net
1330982832 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1330983648 Q * hijacker_ Quit: Leaving
1330983687 Q * bonbons Quit: Leaving
1330983823 Q * clopez Ping timeout: 480 seconds
1330985253 J * Enoria ~Enoria@albaldah.dreamhost.com
1330986227 Q * ghislain Quit: Leaving.
1330987375 J * petzsch ~markus@dslb-092-078-115-163.pools.arcor-ip.net
1330988297 Q * petzsch Quit: Leaving.
1330989013 J * ghislain ~AQUEOS@adsl2.aqueos.com
1330989231 Q * ghislain