[10:37] <amitk> cking: just reading about stress-ng. In CPU compute, can it generate %loading that is frequency invariant? IOW, 50% load at 2GHz != 50% load at 1GHz
[10:40] <cking> amitk, it's not intelligent like that, it just breaks the load into time slices of idle and loaded, so it ignores the clock freq
[10:41] <amitk> cking: ok, we've modified cyclictest for that behaviour and are current modifying rt-app to do the same
[10:42] <amitk> cking: but the memory load might be interesting, I'll check it out
[10:42] <cking> amitk, if you see any niches where I can add more stressors let me know, I'd like to make stress-ng more useful over time
[10:45] <amitk> cking: sure, I'll play around a bit. Our focus hasn't been finding the boundaries (stressing) but more about making it easy for sched maintainers to be able to simulate typical mobile (android) behaviour on a std. linux distro - e.g. mp3 playback, web browsing.
[10:46] <amitk> cking: but i can see stress-ng being useful to setup thermal constraints, for example 
[10:46] <cking> amitk, indeed, stress-ng was more like "how can I fully load a machine and see how much I can make the CPU and cache toasty"
[10:46] <cking> and the old stress tool wasn't really useful enough for what I was playing with
[10:47] <cking> mainly because I was also tinkering with thermald and I wanted to see if I could make that kick on a hot intel box
[10:51] <rbansal1> Hi
[10:51] <rbansal1> Dose someone know, when I am trying to compile Linux 3.14 kernel I get the following error : ERROR: modinfo: could not open /lib/modules/3.14.0/modules.dep 
[10:51] <rbansal1> Why this error is coming ? I tried on Ubuntu and CentOS and on both I get almost similar error
[10:52] <rbansal1> Any clue on this issue will be helpful. 
[13:27] <rtg> apw, I pushed the rebase to 3.16-rc2. I guess we ought to start doing some testing this week.
[13:38] <apw> rtg, yeah, it must be getting close, we should get it in the CKT PPA soon so jibel can test against it
[13:38] <rtg> apw, ah, right. I'll do that today.
[13:47] <rtg> BenC, don't forget to give some love to powerpc64-emb
[13:47] <BenC> rtg: Right, on it, thanks
[13:47] <rtg> BenC, do you think you'll get it figured out this morning ? I'll wait on the first upload if so.
[13:48] <BenC> rtg: I’m hoping so. I’ll know more withing about 15-30 mins
[13:48] <rtg> BenC, cool, will wait for a bit then
[13:50] <BenC> rtg: This is a compile error, correct?
[13:51] <rtg> BenC, yup.
[13:51] <rtg> BenC, link error IIRC
[13:51] <BenC> rtg: Any chance you already have a log of the error?
[13:52] <rtg> BenC, hmm, probably not. all of my local build tests are fairly ephemeral. it wouldn't take but 10 minutes or so to recreate it.
[13:53] <BenC> rtg: I have a build started…
[15:11] <BenC> rtg: I have the fix…one-liner and only affects 85xx (freescale)
[15:13] <rtg> BenC, cool, thats the best kind. I'll probably look at it and think, "Why couldn't I have figured that out ?"
[15:15] <BenC> rtg: The error you saw related to smp_(give|take)_timebase, correct?
[15:15] <BenC> *smp_generic_(give|take)_timebase
[15:17] <rtg> BenC, yup, thats the one
[15:21] <BenC> rtg: Patch sent to kernel-team
[15:33] <apw> smb, hey ... we pulled a lot of VIRT* things =y is that still appropriate
[15:35] <smb> apw, I would assume yes. At least as long as we want to have boot essentials in for virt and bare-metal at the same time.
[15:35] <smb> apw, Of course you could ask me to do that part of the conf review. :)
[15:36] <apw> smb, heh no as long as they are needed i am happy
[15:38] <smb> apw, At least I am under the impression they were. Though things can silently change, so I would not want to bet money on it
[15:39] <infinity> smb: I'm willing to bet a lot of that stuff can be modular, but that requires more than just IRC handwaving. :P
[15:39] <infinity> Like, actual testing.  On multiple arches.  Ick.
[15:40] <smb> infinity, A lot _can_ be modular. The problem with them was that (again at least at some point) there was nothing that would trigger them auto-load
[15:40] <infinity> smb: Well, being auto-loaded is implied in my "can be modular" statement.  If something needs to be manually loaded, that's a no-go.
[15:42] <smb> infinity, Ah ok. So yeah. Some may have changed but agreed, I neither would want things to change without very well tested well.  
[15:43] <infinity> "very well tested well".
[15:43] <smb> textual deja-vu
[15:43] <smb> Or not remembering the word one typed a second ago