On Mon, 26 Aug 2013 10:46:38 +0900 Yoshihiro YUNOMAE <yoshihiro.yunomae...@hitachi.com> wrote:
> > The --date option is used because the two machines are not in sync with > > the trace time stamp. What the date option does, is to sync the > > timestamp up with the gettimeofday and the output reports that. This > > allows the two boxes to report information that is relatively close to > > how the two interacted. > > Oh, I didn't know the --date option. > As you mentioned, we can merge trace data in chronological order by > using --date option if the times of those machines are synchronized by > NTP. > > > If the guest and the host have the same clock, then the --date option > > is not needed and the two should be able to be merged normally. > > No, we can not assure that the guest and the host have the same clock > even if it is running on the same physical machine, because both kernel > doesn't share it, there is some difference between them. So, we still > need time synchronizing guest-host by NTP and --date option. > > However, there are cases that times of those machines cannot be > synchronized. For example, although multiple users can run guests on > virtualization environments (e.g. multi-tenant cloud hosting), there > are no guarantee that they use the same NTP server. Moreover, even if > the times are synchronized, trace data cannot exactly be merged because > the NTP-synchronized time granularity may not be enough fine for > sorting guest-host switching events. Right, unless there's some other means no synchronize between boxes, this is currently the best we have. > > > Also, I haven't released it yet (will soon), but trace-cmd handles > > multiple buffers too. That is, with the multiple buffers that ftrace > > has, it will create and read from them as well as report them. > > Is it commit ID d56f30679f9811a91ed471c8e081cc7ffbed1e62? > We can download the feature from your git repository. Yep. -- Steve -- 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/
