1540341339 Q * any0n Ping timeout: 480 seconds
1540341801 J * any0n ~k@7YZAAAR1W.tor-irc.dnsbl.oftc.net
1540348021 Q * Aiken Remote host closed the connection
1540348249 J * Aiken ~Aiken@b951.h.jbmb.net
1540357674 Q * _pa_ Quit: Leaving
1540364648 M * Ghislain nothing is required, just if this is used and treated like the real thing it was, for me, more logical that it was the same type as if you use kernel function somewhere with those value or pass them down it ca cause overflow issues :)
1540364721 M * Bertl_oO to be hones, I'm not sure what you're talking about ... please elaborate
1540364726 M * Bertl_oO *honest
1540366596 M * Ghislain for exemple (dont know if this is the case) if the total_fork is a value that you got to pass to the kernel at one time and it wait for a 63b value and you give it a 32b it will be a possible issue i guess
1540366641 M * Ghislain i dont know why cvirt is used so i dont know the depth of it but if kernel use 64b and you use a kernel value to base you on it can be > 32b in this way too
1540366738 M * Ghislain that suppose there is value copied from kernel to cvirt or to cvrit to kernel, either dialog could be wrong if the 2 parts are not on the same size
1540366756 M * Ghislain dont know if this is the case or if i am clear on my questionning :)
1540367126 M * Bertl_oO total_fork is a counter introduced by Linux-VServer 
1540367140 M * Bertl_oO we increment it every time a process forks
1540367157 M * Bertl_oO you can retrieve it from /proc or via the Linux-VServer interfaces
1540367179 M * Bertl_oO it is basically 'statistics'
1540367210 M * Bertl_oO it is also designed to 'overflow' eventually, like for example the network counter, etc
1540367264 M * Bertl_oO we could use a 64 bit atomic on 64bit systems for this, but it would quite complicate things by having different interfaces for 32bit and 64bit systems
1540367409 M * Ghislain if it only internal and vserver related this is not an issue, what about the load virtualisation, has it communication to or from the kernel ?
1540367492 M * Ghislain dont know why load is a 64b value, i thing k a load of 32b will allready kills all machiens in the knowned universe :)
1540367623 M * Ghislain but yes i saw that the atomic atomic64 thing is a pain as it is everywhere it is not just one change to the struct
1540367638 Q * hijacker Remote host closed the connection
1540367789 J * hijacker ~nikolay@149.235.255.3
1540368135 M * Ghislain well that is if unsigned long is 64b :)
1540368252 M * Bertl_oO load is uint32_t (no atomic involved)
1540368333 M * Ghislain yes that was i was reading, the kernel is defined as unsigned long int and vserver use uint32_t, so perhaps  that one can be changed more easely  (if it need to )
1540368358 M * Ghislain what do you think, am i being silly ?
1540368365 M * Ghislain i mean more than usual ?
1540368718 M * Bertl_oO where do you see the unsigned long in the kernel?
1540369025 M * Ghislain https://github.com/torvalds/linux/blob/master/kernel/sched/loadavg.c 
1540369025 M * Ghislain calc_load(unsigned long load, unsigned long exp, unsigned long active)
1540369184 M * Bertl_oO we do the calculations in __update_loadavg() which uses unsigned long long :)
1540369205 M * Bertl_oO we could probably reduce it to unsigned long though if you prefer
1540369334 M * Ghislain i dont know it was just reflexion on my mind while trying to see if there was a diff in the kernel vs vserver part that could explain the overflow, but if the kernel use one i think we should use the same type just for consistency :)
1540369399 M * Bertl_oO feel free to submit a tested patch which does that (i.e. change the unsigned long long to an unsigned long)
1540369422 M * Ghislain k
1540370804 J * gastromenia ~mujeebcpy@185.104.252.152
1540371992 Q * Aiken Remote host closed the connection
1540374521 J * Aiken ~Aiken@b951.h.jbmb.net
1540385971 Q * romster Remote host closed the connection
1540387099 Q * Aiken Remote host closed the connection
1540389983 Q * gastromenia Remote host closed the connection
1540390893 Q * any0n Ping timeout: 480 seconds
1540396354 Q * hijacker Quit: Leaving
1540396597 J * any0n ~k@7YZAAASJU.tor-irc.dnsbl.oftc.net
1540414551 J * Aiken ~Aiken@b951.h.jbmb.net
1540417325 J * romster ~romster@158.140.215.184