[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOS58YOMKvb5Gj5CeP6t11NHwSdbZWUJ=uC6aRxd6CxpNrwskg@mail.gmail.com>
Date: Wed, 11 Jan 2012 17:14:11 -0800
From: Tejun Heo <tj@...nel.org>
To: Namhyung Kim <namhyung.kim@....com>
Cc: Namhyung Kim <namhyung@...il.com>, axboe@...nel.dk,
mingo@...hat.com, rostedt@...dmis.org, fweisbec@...il.com,
teravest@...gle.com, slavapestov@...gle.com, ctalbott@...gle.com,
dhsharp@...gle.com, linux-kernel@...r.kernel.org,
winget@...gle.com, Chanho Park <chanho61.park@...sung.com>
Subject: Re: [PATCH RESEND 9/9] block, trace: implement ioblame - IO tracer
with origin tracking
Hello,
On Wed, Jan 11, 2012 at 5:05 PM, Namhyung Kim <namhyung.kim@....com> wrote:
> Yes. But that's a text-based so it might fit better to simple use cases. If
> we need further post processing based on intents, it could be better off
> having binary interface IMHO. And since we already use tracepoints anyway,
> wouldn't it be good to avoid adding another layer of interface or
> complexity?
The thing is that all entries are needed for any post processing, not
only the new ones. To use TP, either there needs to be special
"trigger the TP for all existing entries" switch somewhere or
ioblame/intents file needs to be read for existing entries. Even then,
TPs aren't guaranteed to be reliable. There's no way to detect
overflow and re-emit the event. It just isn't the right interface. The
previous version had intents_bin file in binary format but given that
there aren't too many of intents, binary interface didn't seem
necessary and ripped it out. Adding it back isn't difficult at all but
I'm not sure that's a good idea. It's not like parsing the intents
file is difficult.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists