[13:21] <sturmflut2> cking: Ping
[13:22] <cking> sturmflut2, hiya
[13:23] <sturmflut2> cking: Hey, I ran into an oddity while running eventstat on arale: sometimes the "[swapper]" kernel task shows up as PID 1. Any idea about how that is even possible?
[13:23] <cking> sturmflut2, is that running in a container?
[13:24] <sturmflut2> cking: Not that I know of, and that wouldn't explain it. Strangely enough this is even present in the in-kernel Documentation, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timer_stats.txt#n56
[13:26] <cking> sturmflut2, well, since eventstat uses /proc/timer_stats that's where i'm getting this info from, so it's coming from the kernel and not eventstat per se
[13:26] <sturmflut2> I've never seen it on my Ubuntu 15.04 desktop, but on arale (3.10.x kernel) it's always there
[13:27] <cking> sturmflut2, no idea of the top of my head
[13:27] <cking> s/of/off
[13:28]  * cking has a poke around at the source
[13:29]  * ogra_ finds the etra used/reported memory even more curious than that PID thing
[13:29] <ogra_> *extra
[13:29] <ogra_> since that will for sure have some heavy impact
[13:34] <cking> hrm,  the timers_stats code hasn't radically checked between those kernels, so  I really don't know.
[13:34] <cking> s/checked/changed/
[13:34] <cking> doh
[13:37] <cking> I suspect the comm field (that contains the short process name) for init has been cached after it got created before the process could change it. so just ignore it, it's definitely the correct pid
[13:37] <ogra_> cking, well, probably it sees the swapper from the lxc container (where another init runs that is presented as PID1 inside the container (and outside with a different PID to the host system)
[13:38] <cking> ogra_, that too, event most probably has issues with containers
[13:38] <cking> ..mainly because it has to go on what timer_stats provides as the pid
[13:39] <cking> which can be different for the pid inside the container, argh
[13:39] <ogra_> fun, aint it ? :)
[13:39] <cking> but the cached comm field probably explains the mismatch as shown in the documentation
[13:40] <cking> when dealing with /proc, it's going to be racy :-/
[14:32] <JinqiuYu> hi, there.  I try to compile stree-ng on my cent os host,  and I get " perf.c:77: error: ‘PERF_COUNT_HW_REF_CPU_CYCLES’ undeclared here (not in a function)"  errors , how can I fix it ? 
[14:54] <sturmflut2> cking, ogra_: But the swapper is an in-kernel process. It's the kernel scheduler. It is not part of a container, and I just now found a couple of boxes here at work that don't even run containers, but also show a swapper as PID 1
[14:55] <cking> sturmflut2, as I mentioned earlier, "I suspect the comm field (that contains the short process name) for init has been cached after it got created before the process could change it. so just ignore it, it's definitely the correct pid"
[14:59] <sturmflut2> cking: Yes, something like that probably. But my fear is that if something like this happened and nobody noticed the mismatch, can we trust the rest of the output on arale's kernel
[15:00] <cking> sturmflut2, what do you mean "rest of the output"? that's a wide statement
[15:09] <sturmflut2> cking: If there is one location in the kernel where something allocates a timer, and at this place the wrong information is put into a data structure, can we be sure that it happens only at exactly this one place?
[15:10] <sturmflut2> cking: I too think it's just this one, but it raises a bit of suspicion
[15:11] <cking> sturmflut2, the wrong info is not cached, just that it changes after it got cached. the PID is sane, just the cached comm field my be out of date. but really, since we key off the PID anyhow, it's academic on the name, since the PID is what matters
[15:12] <sturmflut2> cking: I don't think it's the PID that's sane, the full entry in my case is the following
[15:12] <sturmflut2>     1.00     1 [swapper/0]     start_bandwidth_timer     sched_rt_period_timer
[15:12] <sturmflut2> start_bandwidth_timer and sched_rt_period_timer are actual kernel functions in the scheduler
[15:13] <sturmflut2> if the PID is sane, then all of "Task", "Init function" and "Callback" are wrong
[15:15] <sturmflut2> cking: And PID 1 is upstart, which doesn't seem to register a single timer
[15:15] <sturmflut2> cking: I'll have a look at the kernel source code, maybe I can find a definitive answer
[15:16] <cking> sturmflut2, if I had 36 hours in a day, I'd look into it, but for now, this does seem just like a minor issue compared the the other stuff ogra was mentioning
[15:16] <sturmflut2> cking: :)
[15:16] <cking> if there was a process that was eating 50+ wakeups per second, I'd sweat over it
[15:24] <sturmflut2> cking: Let's combine your 24 hours and my 12 hours a day, then we can do it ;)
[15:25] <cking> why not your 24 and my 12 :-)
[15:25] <sturmflut2> cking: Well, Canonical does not (yet) pay for my services ;)
[15:26] <sturmflut2> So I need this thing called "real work"
[15:26] <cking> sturmflut2, ok, me too, canonical pays me at the moment to do some higher priority kernel file system related work ;-)
[15:38] <ogra_> cking, just tell them snappy uses ext4 only anyway :P
[15:38] <ogra_> who needs other filesystems :P
[15:38] <cking> ogra_, the server and cloud folk perchance
[15:38] <ogra_> pfft 
[16:08] <manjo> apw, you know how on tangerine when you schroot it lets you build directories in your home dir ? How was the chroot home linked to user home dir ? 
[17:45] <infinity> manjo: It's a bind mount.
[17:57] <manjo> infinity, thanks.. yes I figured out what I was missing in my profile