On Thu, Mar 26, 2009 at 10:10:32AM +1030, Kevin Shanahan wrote: > 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 Sorry. I guess I was a bit asleep. It's a mistake. So you can restore how it was. Thanks. > 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
