On 2010-10-30 17:47, Mathieu Desnoyers wrote:
> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
> relay dependency to the Generic Ring Buffer Library might be a good
> option to consider.
The blktrace user bits is still (by far) the most wide spread way that
blktrace is used in the field, and those still rely on relayfs. So no,
we can't kill it now.
--
Jens Axboe
* Jens Axboe ([email protected]) wrote:
> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
> > BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
> > transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
> > relay dependency to the Generic Ring Buffer Library might be a good
> > option to consider.
>
> The blktrace user bits is still (by far) the most wide spread way that
> blktrace is used in the field, and those still rely on relayfs. So no,
> we can't kill it now.
What I am proposing is that the Generic Ring Buffer Library could
replace relayfs without changing any of the interfaces blktrace exposes
to user-space. Indeed, I would not remove relayfs unless there was a
replacement.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
On 2010-11-01 09:08, Mathieu Desnoyers wrote:
> * Jens Axboe ([email protected]) wrote:
>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
>>> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
>>> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
>>> relay dependency to the Generic Ring Buffer Library might be a good
>>> option to consider.
>>
>> The blktrace user bits is still (by far) the most wide spread way that
>> blktrace is used in the field, and those still rely on relayfs. So no,
>> we can't kill it now.
>
> What I am proposing is that the Generic Ring Buffer Library could
> replace relayfs without changing any of the interfaces blktrace exposes
> to user-space. Indeed, I would not remove relayfs unless there was a
> replacement.
Sure, I'm open to such a solution as long as it doesn't slow anything
down for blktrace (primary concern, certainly) and retains feature
parity. I'm not married to relayfs, it's just what was available easily
when I added blktrace originally.
--
Jens Axboe
* Jens Axboe ([email protected]) wrote:
>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
>> > BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
>> > transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
>> > relay dependency to the Generic Ring Buffer Library might be a good
>> > option to consider.
>>
>> The blktrace user bits is still (by far) the most wide spread way that
>> blktrace is used in the field, and those still rely on relayfs. So no,
>> we can't kill it now.
On Mon, Nov 1, 2010 at 3:08 PM, Mathieu Desnoyers
<[email protected]> wrote:
> What I am proposing is that the Generic Ring Buffer Library could
> replace relayfs without changing any of the interfaces blktrace exposes
> to user-space. Indeed, I would not remove relayfs unless there was a
> replacement.
We don't in general NAK cleanups because of future features or
removals that may or may not happen.
On 2010-11-01 09:41, Pekka Enberg wrote:
> * Jens Axboe ([email protected]) wrote:
>>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
>>>> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
>>>> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
>>>> relay dependency to the Generic Ring Buffer Library might be a good
>>>> option to consider.
>>>
>>> The blktrace user bits is still (by far) the most wide spread way that
>>> blktrace is used in the field, and those still rely on relayfs. So no,
>>> we can't kill it now.
>
> On Mon, Nov 1, 2010 at 3:08 PM, Mathieu Desnoyers
> <[email protected]> wrote:
>> What I am proposing is that the Generic Ring Buffer Library could
>> replace relayfs without changing any of the interfaces blktrace exposes
>> to user-space. Indeed, I would not remove relayfs unless there was a
>> replacement.
>
> We don't in general NAK cleanups because of future features or
> removals that may or may not happen.
Agree, this is parallel to whether or not we can transition blktrace to
using the generic ring buffer library or not. If the current patch
proposed makes sense, then it should go in regardless of
potential/future plans.
--
Jens Axboe
* Jens Axboe ([email protected]) wrote:
> On 2010-11-01 09:41, Pekka Enberg wrote:
> > * Jens Axboe ([email protected]) wrote:
> >>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
> >>>> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
> >>>> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
> >>>> relay dependency to the Generic Ring Buffer Library might be a good
> >>>> option to consider.
> >>>
> >>> The blktrace user bits is still (by far) the most wide spread way that
> >>> blktrace is used in the field, and those still rely on relayfs. So no,
> >>> we can't kill it now.
> >
> > On Mon, Nov 1, 2010 at 3:08 PM, Mathieu Desnoyers
> > <[email protected]> wrote:
> >> What I am proposing is that the Generic Ring Buffer Library could
> >> replace relayfs without changing any of the interfaces blktrace exposes
> >> to user-space. Indeed, I would not remove relayfs unless there was a
> >> replacement.
> >
> > We don't in general NAK cleanups because of future features or
> > removals that may or may not happen.
>
> Agree, this is parallel to whether or not we can transition blktrace to
> using the generic ring buffer library or not. If the current patch
> proposed makes sense, then it should go in regardless of
> potential/future plans.
Agreed. Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
On Mon, 1 Nov 2010, Mathieu Desnoyers wrote:
> * Jens Axboe ([email protected]) wrote:
> > On 2010-11-01 09:41, Pekka Enberg wrote:
> > > * Jens Axboe ([email protected]) wrote:
> > >>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
> > >>>> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
> > >>>> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
> > >>>> relay dependency to the Generic Ring Buffer Library might be a good
> > >>>> option to consider.
> > >>>
> > >>> The blktrace user bits is still (by far) the most wide spread way that
> > >>> blktrace is used in the field, and those still rely on relayfs. So no,
> > >>> we can't kill it now.
> > >
> > > On Mon, Nov 1, 2010 at 3:08 PM, Mathieu Desnoyers
> > > <[email protected]> wrote:
> > >> What I am proposing is that the Generic Ring Buffer Library could
> > >> replace relayfs without changing any of the interfaces blktrace exposes
> > >> to user-space. Indeed, I would not remove relayfs unless there was a
> > >> replacement.
> > >
> > > We don't in general NAK cleanups because of future features or
> > > removals that may or may not happen.
> >
> > Agree, this is parallel to whether or not we can transition blktrace to
> > using the generic ring buffer library or not. If the current patch
> > proposed makes sense, then it should go in regardless of
> > potential/future plans.
>
> Agreed. Thanks,
>
As I read the discussion over the last day or so, since I last checked my
mail, there are no longer any objections to the patch. Correct?
If that's the case, who will merge it? and should I resend it with various
peoples Acked-by: lines? or?
--
Jesper Juhl <[email protected]> http://www.chaosbits.net/
Plain text mails only, please http://www.expita.com/nomime.html
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
* Jesper Juhl ([email protected]) wrote:
> On Mon, 1 Nov 2010, Mathieu Desnoyers wrote:
>
> > * Jens Axboe ([email protected]) wrote:
> > > On 2010-11-01 09:41, Pekka Enberg wrote:
> > > > * Jens Axboe ([email protected]) wrote:
> > > >>> On 2010-10-30 17:47, Mathieu Desnoyers wrote:
> > > >>>> BLK_DEV_IO_TRACE seems to still select RELAY. Has it completed its
> > > >>>> transition to either Ftrace or Perf ? Depending on Jens, moving blktrace
> > > >>>> relay dependency to the Generic Ring Buffer Library might be a good
> > > >>>> option to consider.
> > > >>>
> > > >>> The blktrace user bits is still (by far) the most wide spread way that
> > > >>> blktrace is used in the field, and those still rely on relayfs. So no,
> > > >>> we can't kill it now.
> > > >
> > > > On Mon, Nov 1, 2010 at 3:08 PM, Mathieu Desnoyers
> > > > <[email protected]> wrote:
> > > >> What I am proposing is that the Generic Ring Buffer Library could
> > > >> replace relayfs without changing any of the interfaces blktrace exposes
> > > >> to user-space. Indeed, I would not remove relayfs unless there was a
> > > >> replacement.
> > > >
> > > > We don't in general NAK cleanups because of future features or
> > > > removals that may or may not happen.
> > >
> > > Agree, this is parallel to whether or not we can transition blktrace to
> > > using the generic ring buffer library or not. If the current patch
> > > proposed makes sense, then it should go in regardless of
> > > potential/future plans.
> >
> > Agreed. Thanks,
> >
>
> As I read the discussion over the last day or so, since I last checked my
> mail, there are no longer any objections to the patch. Correct?
Yes,
Acked-by: Mathieu Desnoyers <[email protected]>
> If that's the case, who will merge it? and should I resend it with various
> peoples Acked-by: lines? or?
Yep, this might make the maintainer's work easier, I think. As for who
will merge it, good question. Andrew ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com