Show pageOld revisionsBacklinksBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ==== DTrace changes - George Neville-Neil ==== * CADETS projects for distributed tracing * Solve interesting problems re: security and who did what to whom and when * We would like always-on instrumentation but this is costly (military doesn't care) * Language enhancements * New data types including Event UUIDs to provide unique and persistent names for structures that may otherwise be ephemeral in the kernel (not yet upstreamed) * Sequences, loops and branches (!!!) * Currently something upstreamed for ifs, but designed badly so will probably be redone * Improve performance of aggregate types, which are currently very slow * Pull DTrace out into a library so it can be easily consumed by many tools * Note: look at Node.js DTrace consumer * Enhanced network tracing * Providers: IP, UPDT, TCP, TCP debug, SIFTR * Added mbuf tracing * new mbuf translator mbuf.d * upstreamed into %%FreeBSD%% * eventually to be part of "fbsd:::" provider * Machine readable output with libxo (researching binary format) * Impose an object model/structured data on DTrace to make information processing easier (maybe even write scripts in a real language) * Bi-weekly DTrace call hosted by the Foundation (ask to join) * %%OpenDTrace%% Initiative and [[/GitHub|GitHub]] organization ==== Distributed Tracing - Graeme Jenkinson ==== * CADETS work: tool that users interact with like DTrace but that distributes query expressions over many hosts and tracks inter-node information and interactions * Want real people to use this, leverage awareness of DTrace * Instead of printing out a DTrace trace log to a user, send it to a central location for aggregation * Analyst writes D scripts, gives them to Apache Zookeeper which handles distributing the relevant scripts to nodes * Output generated as JSON and sent to a distributed commit log for consumption by a stream processor (vector clocks used to determine order) * Is a distributed commit log the right abstraction? Will people actually set up this infrastructure for distributed tracing? ==== Security Audit Event Framework - Robert Watson ==== * We have a security audit framework similar to that of Solaris, but it is becoming out of date as new services are added, and it isn't designed to handle events coming from RPC frameworks * Orange Book spec not entirely current, additional functionality had to be added * DTrace provider that lets D scripts hook into the audit system * We plan to upstream many changes to the audit framework in the coming months * Problem: audit tries to be reliable, while DTrace throws away data points if overloaded; the audit provider will have the logging capabilities of audit but not the reliability ==== DTrace Security Issues - Samuel Lepetit ==== * For xnu: * How can we implement DTrace without leaking KASLR slide? * How can we implement DTrace if kernel .text is read only? * create a separate virtual mapping window for the instruction to be patched * this won't work because Apple don't want anyone touching the kernel ever * How can we implement DTrace to allow non-root users to trace userspace applications safely? * Only allow certain probes/fire in appropriate places ==== Resourceful - Lucian Carata ==== * Performance measurements in context * Benchmarking is hard, debugging performance is even harder (uses same tools, though) * You need to make sure you're measuring what you think you're measuring * Fewer tools for this * Multiplexed resources and asynchronicity are issues * Resourceful is a tool that tries to solve these problems * Low-overhead kernel probing that is aware of muxing and asynchronicity * Lets applications self-monitor and communicate what they're measuring * "How many cache misses happened during request A" when request A is muxed with potentially hundreds of other requests * Kamprobes lightweight and probe at call site ==== Gem5 - Bjoern Zeeb ==== * Microarchitectural simulator * Useful suspend/resume features for testing * Not cycle accurate * Detailed instruction trace/cache events * Trying to run full BSD system, still some bugs * These will be fixed by end of %%PhD%% * Want to use Gem5 to analyze the effects of changing hardware properties on software (cache sizes etc.) * Compare Gem5 results to real hardware observations devsummit/201608/tracing.txt Last modified: 2016/08/16 17:19by BrettGutstein