On Mon, 2 Jul 2018 17:04:18 +0300
"Yordan Karadzhov (VMware)" <y.karadz@xxxxxxxxx> wrote:
> diff --git a/kernel-shark-qt/src/libkshark.h b/kernel-shark-qt/src/libkshark.h
> new file mode 100644
> index 0000000..b59c94c
> --- /dev/null
> +++ b/kernel-shark-qt/src/libkshark.h
> @@ -0,0 +1,114 @@
> +/* SPDX-License-Identifier: LGPL-2.1 */
> +
> +/*
> + * Copyright (C) 2017 VMware Inc, Yordan Karadzhov <y.karadz@xxxxxxxxx>
> + */
> +
> + /**
> + * @file libkshark.h
> + * @brief API for processing of FTRACE (trace-cmd) data.
> + */
> +
> +#ifndef _LIB_KSHARK_H
> +#define _LIB_KSHARK_H
> +
> +// C
> +#include <stdint.h>
> +#include <pthread.h>
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +// trace-cmd
> +#include "trace-cmd.h"
> +#include "event-parse.h"
> +#include "trace-filter-hash.h"
> +
Making updates, I notice some issues here.
> +/**
> + * Kernel Shark entry contains all information from one trace record needed
> + * in order to visualize the time-series of trace records. The part of the
> + * data which is not directly required for the visualization (latency, record
> + * info etc.) is available on-demand via the offset into the trace file.
> + */
> +struct kshark_entry {
> + /**
> + * A bit mask controlling the visibility of the entry. A value of OxFF
> + * would mean that the entry is visible everywhere.
> + */
> + uint8_t visible;
> +
> + /** The CPU core of the record. */
> + uint8_t cpu;
One byte is too small. We already have boxes that I trace with over
1000 CPUs.
> +
> + /** The PID of the task the record was generated. */
> + int16_t pid;
16bits is too small for pid. There's work to have it grow to 32 bits.
I know it's going to take up more memory, but both of these will need
to grow to at 32bits. Perhaps we can combine the cpu and visible into
one 32 bits, where we reserve the MSBs for flags for visible. But to do
that, one needs to be concerned about updates to them.
-- Steve
> +
> + /** Unique Id ot the trace event type. */
> + int event_id;
> +
> + /** The offset into the trace file, used to find the record. */
> + uint64_t offset;
> +
> + /**
> + * The time of the record in nano seconds. The value is taken from
> + * the timestamps within the trace data file, which are architecture
> + * dependent. The time usually is the timestamp from when the system
> + * started.
> + */
> + uint64_t ts;
> +
> + /** Pointer to the next (in time) kshark_entry on the same CPU core. */
> + struct kshark_entry *next;
> +};
> +
|