On Mon, Dec 15, 2014 at 09:17:33PM +0000, Liang, Kan wrote: > > This doesn't seem to make any kind of sense, and its weirdly implemented. > > > > So why would you push anything to the original parent? Your description > > states that the parent event usually has 1, and then you argue about fixing > > that by using the orig parent, but then you need to update the orig parent. > > Did you go in circles and confuse yourself? Why not push things into the > > regular parent event if you're going to push things up. > > My thought is that the original parent is the root of the tree.
No parent is the root; I thought your orig parent thing was the event you forked from, but now I see its not. See inherit_event(), event->parent is the root event. > If there is an > average sample period for nodes, it should be kept in the root node, since > it's the only node everyone knows. Right, but, that's also contention central.. > > Also, since you can have multiple child events, on many CPUs local64_t is > > the wrong data type, furthermore its going to be a scalability issue on big > > hardware. > > I'd like to have avg_sample_period for each CPU. The similar usage is > period_left in hw_perf_event. Well, some events are per cpu, some are per task. The per task events do not have per-cpu storage and their parent can be on whatever cpu. > We don't need to share the avg_sample_period between CPUs, after all > it's only a reference. Right, some smarts are needed to avoid the worst contention there. Maybe a jiffy timestamp and don't update more than once every HZ jiffies or so. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
