forked from Minki/linux
0dcbcbb49e
* Dan Carpenter <dan.carpenter@oracle.com> wrote: > Sparse complains that these signed bitfields look "dubious". The > problem is that instead of being either 0 or 1 like people would expect, > signed one bit variables like this are either 0 or -1. It doesn't cause > a problem in this case but it's ugly so lets fix them. * walter harms (wharms@bfs.de) wrote: > hi, > This patch looks ok to me but this design is ugly by itself. > It should be replaced by an uchar uint whatever or use a > real bool (obviously not preferred by this programmes). bool :1, uchar :1 or uint :1 could make sense. uchar:1/bool:1 won't save any space here, because the surrounding fields are either uint or pointers, so alignment will just add padding. I try to use int/uint whenever possible because x86 CPUs tend to get less register false-dependencies when using instructions modifying the whole register (generated by using int/uint types) rather than only part of it (uchar/char/bool). I only use char/uchar/bool when there is a clear wanted space gain. The reason why I never use the bool type within a structure when I want a compact representation is that bool takes a whole byte just to represent one bit: struct usebitfield { int a; unsigned int f:1, g:1, h:1, i:1, j:1; int b; }; struct usebool { int a; bool f, g, h, i, j; int b; }; struct useboolbf { int a; bool f:1, g:1, h:1, i:1, j:1; int b; }; int main() { printf("bitfield %d bytes, bool %d bytes, boolbitfield %d bytes\n", sizeof(struct usebitfield), sizeof(struct usebool), sizeof(struct useboolbf)); } result: bitfield 12 bytes, bool 16 bytes, boolbitfield 12 bytes This is because each bool takes one byte, while the bitfields are put in units of "unsigned int" (or bool for the 3rd struct). So in this example, we need 5 bytes + 3 bytes alignment for the bool, but only 4 bytes to hold the "unsigned int" unit for the bitfields. The choice between bool and bitfields must also take into account the frequency of access to the variable, because bitfields require mask operations to access the selected bit(s). You will notice that none of these bitfields are accessed on the tracing fast-path: only in slow-paths. Therefore, space gain is more important than speed here. One might argue that I have so few of these fields here that it does not make an actual difference to go for bitfield or bool. I am just trying to choose types best suited for their intended purpose, ensuring they are future-proof and will allow simply adding more fields using the same type, as needed. So I guess I'll go for uint :1. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Acked-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
||
|---|---|---|
| .. | ||
| instrumentation | ||
| lib | ||
| probes | ||
| wrapper | ||
| Kconfig | ||
| LICENSE | ||
| ltt-context.c | ||
| ltt-debugfs-abi.c | ||
| ltt-debugfs-abi.h | ||
| ltt-endian.h | ||
| ltt-events.c | ||
| ltt-events.h | ||
| ltt-probes.c | ||
| ltt-ring-buffer-client-discard.c | ||
| ltt-ring-buffer-client-mmap-discard.c | ||
| ltt-ring-buffer-client-mmap-overwrite.c | ||
| ltt-ring-buffer-client-overwrite.c | ||
| ltt-ring-buffer-client.h | ||
| ltt-ring-buffer-metadata-client.c | ||
| ltt-ring-buffer-metadata-client.h | ||
| ltt-ring-buffer-metadata-mmap-client.c | ||
| ltt-tracer-core.h | ||
| ltt-tracer.h | ||
| lttng-calibrate.c | ||
| lttng-context-nice.c | ||
| lttng-context-perf-counters.c | ||
| lttng-context-pid.c | ||
| lttng-context-ppid.c | ||
| lttng-context-prio.c | ||
| lttng-context-procname.c | ||
| lttng-context-tid.c | ||
| lttng-context-vpid.c | ||
| lttng-context-vppid.c | ||
| lttng-context-vtid.c | ||
| lttng-syscalls.c | ||
| Makefile | ||
| README | ||
| TODO | ||
LTTng 2.0 modules Mathieu Desnoyers November 1st, 2011 LTTng 2.0 kernel modules is currently part of the Linux kernel staging tree. It features (new features since LTTng 0.x): - Produces CTF (Common Trace Format) natively, (http://www.efficios.com/ctf) - Tracepoints, Function tracer, CPU Performance Monitoring Unit (PMU) counters, kprobes, and kretprobes support, - Integrated interface for both kernel and userspace tracing, - Have the ability to attach "context" information to events in the trace (e.g. any PMU counter, pid, ppid, tid, comm name, etc). All the extra information fields to be collected with events are optional, specified on a per-tracing-session basis (except for timestamp and event id, which are mandatory). To build and install, you need to select "Staging" modules, and the LTTng kernel tracer. Use lttng-tools to control the tracer. LTTng tools should automatically load the kernel modules when needed. Use Babeltrace to print traces as a human-readable text log. These tools are available at the following URL: http://lttng.org/lttng2.0 Please note that the LTTng-UST 2.0 (user-space tracing counterpart of LTTng 2.0) is now ready to be used, but still only available from the git repository. So far, it has been tested on vanilla Linux kernels 2.6.38, 2.6.39 and 3.0 (on x86 32/64-bit, and powerpc 32-bit at the moment, build tested on ARM). It should work fine with newer kernels and other architectures, but expect build issues with kernels older than 2.6.36. The clock source currently used is the standard gettimeofday (slower, less scalable and less precise than the LTTng 0.x clocks). Support for LTTng 0.x clocks will be added back soon into LTTng 2.0. Please note that lttng-modules 2.0 can build on a Linux kernel patched with the LTTng 0.x patchset, but the lttng-modules 2.0 replace the lttng-modules 0.x, so both tracers cannot be installed at the same time for a given kernel version. * Note about Perf PMU counters support Each PMU counter has its zero value set when it is attached to a context with add-context. Therefore, it is normal that the same counters attached to both the stream context and event context show different values for a given event; what matters is that they increment at the same rate.