On Fri, 2 Jun 2017 11:59:11 +0200 Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > On 2017-05-26 11:25:02 [-0500], Clark Williams wrote: > > What we're looking for is how people are using cyclictest. For example, at Red Hat we use the 'rteval' tool, which puts a large SCHED_OTHER load on the system and then runs cyclictest with a measurement thread on each core. The intent is to put a large load on the scheduler and prove that the RT patchset provides deterministic performance under load. > > > > What other types of testing/measurement are people doing with cyclictest? > > hackbench, disk I/O, network related ping/traffic for the "normal" > interfaces and some custom ones to poke at the gpio, i2c, … drivers to > ensure that they don't a long off time. Either way, I prefer starting > them independently of cyclictest. Yeah, that's the *other* tool we should discuss some time: rteval. Currently the only loads rteval has are 'kcompile', which is a parallel make of a kernel tree and 'hackbench' which kicks off a bunch of hackbench instances. I've been thinking about adding a 'stress' load to use the stress app, but just haven't had time. And of course the only measurement module for rteval is cyclictest. Haven't really figured out what would be another good measurement module. > > > John Kacur and I are wanting to clean up tracing and make sure that the most commonly used options are on by default. In addition we want to refactor some of the runtime logic. Are there other areas that need to be cleaned up? Features that need to be added/deleted? > > I do have (had) a tiny version of cyclictest with a lot things pulled > out simply to get it run a system with 8 MiB RAM in total. Learned from > this: everything out :) > Basically the only interaction between cyclictest and the tracing > infrastructure should be just to stop tracing only if a break value was > specified _and_ was the reason for cyclictest to abort. > This would also reduce the number of command line options which would > _really_ nice. That's exactly the plan. Rip out the tracing bits (except for -b/--breaktrace) and their associated command line args. > As for defaults, it should be have those arguments which are used by > people by default. I guess this includes clock_nanosleep(), mlockall(), > very high priority, one thread per-core and so on. > Not sure about "-d 0 --secaligned 250" but something should be default > so we have the same behaviour on its invocation. When rteval starts cyclictest it uses '-d0 -i100'. I know that's the worst case of having every timer interrupt fire at the same time, but when we started this that's what we wanted to see. Do we need to have two meta-arguments: --worst-case / --best-case? The --worst-case would do things most normal deployers of a realtime app wouldn't do, while the --best-case would stagger timer starts, isolate to numa nodes, etc. > I remember, that there was (or is) an option to figure out if the > hrtimer is working on the system and estimates the resolution of the > clocksource. I would move that into a different tool. > That -M mode is nice, but it should give some kind of indication, that > the system is still alive like update the number of "loop" once in a > while. But this brings me to another topic: The output system. Usually > the console output is enough. Then we have the "histogram" mode to check > the distribution. People often use the histogram mode because the former > can't be used/parsed by script/tool. Here (the histogram) I hear people > complaining about the output which is not (easy) > machine-readable. *I* think it would be okay to use the "histogram" mode > for machine-readable but the output should be better structured. > Something like yaml is probably just fine. However I can't tell if this > will work for everyone or if a plugin-like interface would be best so we > can dock yaml output as well as something that creates xml based output > (for people that dream in XML, too). I don't have a problem generating XML or JSON or some sort of structured output. I'll put that on the list. Hmmm, plugins... Regarding periodic updates, what do you think about providing a way for an app to query the current state of a run? Possibly a memory region that can be mmapped by a process? Or possibly a UNIX domain socket? I'm thinking of the case where you're doing a 48 hour test run on a box where you don't have easy access to the console and would just like to know if a) the box is alive and b) is still showing reasonable values for max latency and jitter. I kinda like the memory region since that's how cyclictest handles output: the measurement threads all dump their data into a cpu-specific memory area and a display thread (running at a low priority) is the one that wakes up, reads the update and printf's to the screen. If we exported that region so that another process could mmap it read-only, that would provide a way to get a snapshot of the run, without actually depending on cyclictest to *do* anything out of the ordinary. Thanks for the input Sebastian. Clark -- The United States Coast Guard Ruining Natural Selection since 1790
Attachment:
pgpFZ4kPtSdHD.pgp
Description: OpenPGP digital signature
