1516579811 M * Le_Coyote misc--: "easy" and "vserver" don't usually go hand in hand :) 1516579862 Q * gnarface Remote host closed the connection 1516580142 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1516580916 M * misc-- hehe 1516580918 M * misc-- no 1516581216 Q * fstd Remote host closed the connection 1516581218 J * fstd ~fstd@xdsl-87-79-40-2.netcologne.de 1516581580 Q * fstd Remote host closed the connection 1516581786 J * fstd ~fstd@xdsl-87-79-40-2.netcologne.de 1516581986 Q * fstd Remote host closed the connection 1516582291 M * misc-- hmm if I build a new vserver, can I just copy /etc/vservers and /vservers from a previous vserver to the current server and it will work? 1516582304 M * misc-- (once kernel/software installed obviously) 1516582712 J * fstd ~fstd@xdsl-195-14-216-84.netcologne.de 1516582989 M * Le_Coyote misc--: that should work, as long as it's a full copy (hidden dirs etc) 1516584151 M * misc-- cool 1516589909 Q * obeardly Remote host closed the connection 1516590626 N * Bertl_oO Bertl_zZ 1516601928 M * Guy- misc--: be sure to also copy xattrs; rsync -aHSAX or similar 1516601972 M * Guy- misc--: and if you use hashification and are copying several vservers, you'll need something like find /vservers/. -type f -links +2 -exec setattr --iunlink {} + 1516605969 Q * romster Remote host closed the connection 1516605994 J * romster ~romster@158.140.215.184 1516606808 Q * Riviera Remote host closed the connection 1516609728 J * nikolay ~nikolay@149.235.255.3 1516609991 Q * romster Remote host closed the connection 1516610014 J * romster ~romster@158.140.215.184 1516610470 Q * romster Remote host closed the connection 1516610492 J * romster ~romster@158.140.215.184 1516618100 N * Bertl_zZ Bertl 1516618103 M * Bertl morning folks! 1516618170 M * nikolay morning Bertl 1516619509 M * Ghislain morning 1516619549 M * Ghislain Bertl: my first patch with division was working but since then all other fail to work 1516619574 M * Ghislain seems i am very bad at logic 1516619599 M * Ghislain also someone posted a virt_load patch for 4.4 and 4.9: https://pastebin.com/A0RF1UEh 1516619667 M * Bertl ah, yes, I think I already incorporated that one 1516619701 M * Bertl when I'm through with my emails, we can look into the VIRT_MEM logic 1516619711 M * Bertl I have some instrumentation patches ready 1516619739 M * Ghislain basicaly we must for each val-> change to test mem_unitse 1516619749 M * Ghislain but i dont know wwhy all my try fail 1516619758 M * Ghislain i must be really bad at programming 1516619768 M * Ghislain which do not fare well for a sysadmin 1516619865 M * Bertl sometimes it is trickier than you think ... 1516619942 M * Bertl note that there are already three cases ignoring the arch differences for VIRT_MEM 1516619951 M * Bertl 1) no memcg 1516619962 M * Bertl 2) unlimited memory (cg) 1516619969 M * Bertl 3) limited memory (cg) 1516620033 M * Bertl and things don't get easier by the fact that the sys_info struct is used in several kernel-userspace interfaces 1516620120 M * Ghislain about that the test on res_limit should be moved up 1516620133 M * Ghislain no need to call the 3 other functions if we goto out 1516620407 M * Ghislain i 'll try one last time 1516624618 M * Bertl okay ... 1516624630 M * Bertl off for a little, bbs 1516624635 N * Bertl Bertl_oO 1516625952 M * Ghislain okay that do not work at all, here is th patch: https://pastebin.com/raw/ztKMNztw i dont understand where my logic fails 1516626205 M * Ghislain if anyone want to enlighten me this bothers me quite a lot 1516629647 M * AlexanderS Ghislain: Just by looking at your patch: Your code does not set val->freeram if res_limit == PAGE_COUNTER_MAX. (Before the patch the setting was outside of the if) 1516630083 M * AlexanderS (Maybe the code would get cleaner, if you set a helper variable at the top to PAGE_SHIFT or 0 depending on mem_unit and always shift by this variable.) 1516631096 J * obeardly ~obeardly@12.153.3.33 1516631296 M * Ghislain thanks a lots, i will look into this right now 1516633412 M * Ghislain i was toying with the idea of defining this kind of constant also. It ouwl help but i was stopped because i dont have a clue about what do >> or << so i was not knowing what to put in it to make it do nothing 1516633495 M * Ghislain also reading on some blog it seems * PAGE_SIZE versus << PAGE_SHIFT , the first could be better optimised by recent compiler that will use SHIFT or special cpu tricks to make it the best possible 1516634541 M * AlexanderS << and >> just moves the bits by the number of positions. 1516634598 M * Ghislain yes i got htat, but what does it really means instead of just making giberish ot the data 1516634600 M * Ghislain :) 1516634773 M * AlexanderS Does wikipedia explains your question: "A left arithmetic shift by n is equivalent to multiplying by 2^n (provided the value does not overflow), while a right arithmetic shift by n of a two's complement value is equivalent to dividing by 2^n and rounding toward negative infinity". 1516635485 M * Ghislain Any sufficiently advanced binary is indistinguishable from magic 1516635767 M * Ghislain ok, trying by allways shifting with a defined value depending on test 1516635903 M * Ghislain muchhhhh simpler codewise...compiling... 1516636165 Q * obeardly Quit: Leaving 1516637336 M * Ghislain nope 1516637354 M * Ghislain whatever i do used memory is allways in pages not in bytes 1516637596 M * Ghislain https://pastebin.com/raw/TA439F4h 1516637883 M * Ghislain hum i wonder if there is not an issue in memcontrol with a shift allready 1516637960 M * AlexanderS The values in val should be pages or bytes? 1516637979 M * Ghislain val is a sysinfo, it depends on mem_unit 1516637995 M * Ghislain mem_unit=1 => byte, mem_unit =PAGE_SIZE => PGES 1516638077 M * AlexanderS Ah I see. And the mem_cgroup_.. stuff is always in PAGES? 1516638828 M * Ghislain okay i think i found the issue 1516638859 M * Ghislain mem_cgroup_usage returns pages, before it returned bytes AND mem_unit changed 1516638870 M * Ghislain so i must change both 1516638989 M * Ghislain oh that shounds good, if this solve my issue that will rekindle the hope in my little brain 1516639016 M * Ghislain thanks for looking at it it helps not to be alone when you are not very confident :) 1516639543 Q * nikolay Quit: Leaving 1516642787 M * Ghislain that seems to work ! :) 1516643799 M * Ghislain bertl: it works ! virt_mem, memory and swap are ok :) 1516643870 M * Ghislain logic was not the issue it was a double change in mainline, a function that returns page instead of bytes and the memù_unit that changed too. I sent my patch to the list to review :) 1516645745 J * obeardly ~obeardly@12.153.3.33 1516650218 M * Bertl_oO Ghislain: excellent! will check shortly! 1516653080 M * Ghislain cool 1516653141 M * Ghislain i looked into the kernel code and they use a lot in sys.c xxx * PAGE_SIZE and not xxx << PAGE_SHIFT 1516653159 M * Ghislain i saw that some say the compiler better optimise the * 1516653187 M * Ghislain Fyi 1516653292 M * Bertl_oO yeah, both is fine 1516653338 M * Bertl_oO I'm not convinced about the u64 page_or_byte though :) 1516653343 M * Ghislain i stiked to a shift but the * is so more readable for a newby like me 1516653408 M * Ghislain well we can use a int i was just using the very same type as the diverse counter not knowing if this was better or not to compare value of the same size 1516653437 M * Bertl_oO btw, the /* memory unlimited */ check and early out is wrong 1516653448 M * Ghislain it must be > PAGE_SIZe so anything can fit i guess 1516653483 M * Ghislain hum why ? it was just after 3 more call that where not used if the out was called no ? 1516653499 M * Bertl_oO yes, that was wrong too I think 1516653518 M * Bertl_oO in case we have no limit but a cgroup, we still have cgroup specific usage 1516653529 M * Bertl_oO (just no upper limit) 1516653542 M * Ghislain yes i see 1516653562 M * Ghislain so i optimized an error, this error was for more efficient like this ! 1516653570 M * Bertl_oO yes :) 1516653579 M * Bertl_oO way more effective now :) 1516653638 M * Ghislain you will not be able to take away my tshirt 'i am a vserver kernel developper' ! 1516653673 M * Ghislain by the way it seems that kmem cgroup account dentry cache inode cache and others 1516653688 M * Ghislain so perhaps the dentry calls could be removed from 4.4+ 1516653690 M * Bertl_oO yes, kmem is new in 4.9 IIRC 1516653714 M * Ghislain ok 4.9 sorry i was thinking 4.4 had it too 1516653724 M * Ghislain kind of mixing things lately 1516653752 M * Bertl_oO might be 4.4 too, but I remember reading up on it once I saw it 1516653863 M * Ghislain slab seems to incorporate a lot, tcp cache dentry inode name caches, arp cache... 1516653879 M * Ghislain its less specialised but limit more broadly 1516653971 M * Ghislain i wanted to create some test case but i was unsuccessful working with context in the open without vcreating a guest frst 1516654040 M * Ghislain so as soon as i got time i will try to make some with a full guest and ask your and daniel help to make it independant 1516654085 M * Ghislain must go, see ya, if you need testing i must tell 4.9.77 testme testfs and start/stop guest is ok with patch + ipv6, 64b and my patches 1516654107 M * Bertl_oO okay, tx! 1516654115 M * Ghislain ping me i will test anything you'll trhow at me until next time :) 1516654118 M * Ghislain ++ 1516654443 M * Aiken there is a patch for ipv6 or you finally selected ipv6? 1516654473 M * Aiken or that patch from the other day when the kernel did not compile when you did not have ipv6 selected? 1516654497 M * Bertl_oO http://vserver.13thfloor.at/Experimental/delta-ipv6-fix04.diff 1516654499 M * Aiken I have the morning can test here 1516654512 M * Bertl_oO it's from january 16th 1516654525 M * Bertl_oO should fix compile with and without ipv6 1516654567 M * Aiken from that day the kernel was compiling with Ghislain's config with ipv6 enabled without the patch 1516654595 M * Bertl_oO yes, when it is enabled, it's fine 1516658603 Q * obeardly Quit: Leaving 1516661994 M * misc-- Guy-: thanks. Actually when I backed up the vservers I didn't use --numeric-ids so my perms were all screwed. All fixed now though but was a pain. Not using vhashify so don't need to restore the link flags 1516662647 J * Ghislain1 ~ghislain@81.56.195.31 1516662671 Q * Ghislain Read error: Connection reset by peer