[15:02] <om26er> jsalisbury, re bug 1627108, the latest kernel is bad as well.
[15:02] <jsalisbury> om26er, ack, thanks.  I'll build the next one.
[16:14] <om26er> jsalisbury, Hi! same results with the new build. Could you maybe build a few versions together to fasten the testing ?
[16:15] <apw> om26er, that is a bisect, the next step depends on whether it works or fails with each test
[16:16] <jsalisbury> om26er, ack.  what apw said :-)  
[16:16] <om26er> apw, hmm, is that an automated process ?
[16:17] <apw> semi-automated is the best description
[17:40] <om26er> jsalisbury: that's a good kernel.
[17:41] <jsalisbury> om26er, ack, thanks.  Next one coming shortly.
[18:19] <manjo> rtg, is CONFIG_MEMCG_SWAP_ENABLED is disabled coz of potential high memory consumption ? 
[18:21] <rtg> manjo, looks like you can enable it on boot command line, "swapaccount=1"
[18:22] <manjo> rtg, yes .. but the reason for having it disabled by default is mem consumption ?
[18:22] <rtg> manjo, heck if I know.
[18:22] <manjo> ☺ 
[18:27] <manjo> rtg, also arm64 sets CONFIG_NR_CPUS=128 and amd64 sets it to 256, can we make a case to make them match for 17.04 ? ie increase 128 -> 256 for arm64 ?
[18:28] <manjo> rtg, I know it is premature atm.. but trying to see if there any opposition
[18:28] <rtg> manjo, I actually had  CONFIG_NR_CPUS=8192 for awhile, but I think that setting was regressed during Beta2
[18:28] <rtg> 8192 for amd64
[18:29] <manjo> rtg, was it regressed due to bug ?
[18:29] <rtg> manjo, no, other reasons
[18:30] <manjo> rtg, ic .. May be we can revist bumping arm64 to match amd64 in 17.04
[18:30] <rtg> manjo, I will restore it for 17.04
[18:30] <manjo> rtg, cool
[18:32] <manjo> rtg, I will have a list for you for 17.04 wrt arm64 .. 
[18:32] <om26er> jsalisbury, that is a good kernel as well, but it seems to say that its 4.7-rc5, probably wrong name ? 
[18:32] <rtg> manjo, perhaps you should start a bug, assign me, and milestone it for 17.04
[18:32] <manjo> yep .. I am doing a review based on a proposal .. will open a bug and assign you
[18:33] <om26er> apw, Hello! any update on bug 1622655 ?
[18:34] <manjo> rtg, one pita config that is coming up for arm64 is 64k page support.. I know we beat this horse to death last time... but it still is a popular request
[18:34] <jsalisbury> om26er, thanks.  The bisect bounces around.  The naming is done by the mainline-build-one script in kteam-tool.  I've never looked at how the naming is done, but I assume it has to do with the closed tag to the commit.
[18:34] <jsalisbury> om26er, for example, that commit:
[18:34] <jsalisbury> git describe 5048c2af078d5976895d521262a8802ea791f3b0
[18:34] <jsalisbury> v4.7-rc5-679-g5048c2a
[18:35] <manjo> rtg, I have 2 people claim perf improvements with 64k pages .. we do have it enabled for ppc64el
[18:35] <om26er> I only understood some of that :)
[18:36] <manjo> rtg, I hate to bring it up again .. but is this something we should explore again? 
[18:39] <manjo> rtg, if it is a strong no from your side it is a no .. but if it is a possibility for arm64 I can try to gather some data
[18:39] <rtg> manjo, I'm not an expert on that. Perhaps dannf would be a better resource ?
[18:40] <manjo> rtg, let me sync with him on other socs we enable and see what we comeup with
[18:41] <manjo> rtg, iirc last time we beat on this horse .. he did try to make an argument for 64k pages.. 
[18:42] <rtg> manjo, I've got no skin in that game. If it works then I'm fine with it. 
[18:43] <manjo> rtg, ack .. will get back to you after I talk it over with dannf 
[18:44] <manjo> rtg, target is 17.04 .. so lots of time to gather any proof / data points 
[18:44] <rtg> yup
[19:04] <dannf> rtg, manjo : PoR is not to do 64K pages. there are plenty of negatives - and most of hte positives can be achieved (or improved by) hugepages
[19:05] <dannf> we discussed this at a sprint w/ various teams already
[19:05] <rtg> dannf, yeah, seems like I turned it off once