On Tue, 2009-03-24 at 12:44 +0100, Frederic Weisbecker wrote: > Sorry, I've been late to answer. > As I explained in my previous mail, you trace is only > a snapshot that happened in 10 msec. > > I experimented different sizes for the ring buffer but even > a 1 second trace require 20 Mo of memory. And a so huge trace > would be impractical. > > I think we should keep the trace filters we had previously. > If you don't minde, could you please retest against latest -tip > the following updated patch? Iadded the filters, fixed the python > subshell and also flushed the buffer more nicely according to > a recent feature in -tip: > > echo > trace > > instead of switching to nop. > You will need to pull latest -tip again. Ok, thanks for that. I'll get a new -tip kernel ready to test tonight. I'm not sure about the change to the python subshell though: > while [ "$found" != "True" ] > do > # Flush the previous buffer > echo trace > $prefix/trace > > echo 1 > $prefix/tracing_enabled > lat=$(ping -c 1 $addr | grep rtt | grep -Eo " [0-9]+.[0-9]+") > echo 0 > $prefix/tracing_enabled > > echo $lat > found=$(python -c "print float(str($lat).strip())") > sleep 0.01 > done kmshanah@kulgan:~$ python -c "print float(str(1.234).strip())" 1.234 That's not going to evaluate to "True" at all is it? What happened to the test against the latency threshold value? Did you mean something like this? kmshanah@kulgan:~$ python -c "print float(str(1.234).strip()) > 5000" False kmshanah@kulgan:~$ python -c "print float(str(5001.234).strip()) > 5000" True Cheers, Kevin. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
