[dm-devel] [PATCH 7/7] dm: optimize clone_rq() when track_peak_rq_based_ios is disabled
Mike Snitzer
snitzer at redhat.com
Thu Sep 12 23:53:46 UTC 2013
On Thu, Sep 12 2013 at 7:30pm -0400,
Mikulas Patocka <mpatocka at redhat.com> wrote:
>
>
> On Thu, 12 Sep 2013, Mike Snitzer wrote:
>
> > On Thu, Sep 12 2013 at 7:00pm -0400,
> > Mikulas Patocka <mpatocka at redhat.com> wrote:
> >
> > >
> > >
> > > On Thu, 12 Sep 2013, Mike Snitzer wrote:
> > >
> > > > Make use of static keys to eliminate the relevant branch in clone_rq()
> > > > when dm_mod's 'track_peak_rq_based_ios' paramter is set to 0 (disabled).
> > > >
> > > > Even if 'track_peak_rq_based_ios' is set to 0 it will not take effect
> > > > until the next request-based table reload. Once it is disabled the
> > > > 'peak_rq_based_ios' parameter will be reset to 0.
> > >
> > > This patch changes it so that the value track_peak_rq_based_ios is sampled
> > > only when reloading a table. I think it will be confusing to the user if
> > > he changes the value, but the change doesn't take effect until something
> > > reloads some table.
> >
> > Well we need to be able to notice the change but I do not wish to do so
> > in a performance critical path (which clone_rq is).
>
> I think one condition isn't that bad so there is no need to use static
> keys.
Considering we're talking about the IO path I'd rather avoid it given
'track_peak_rq_based_ios' will almost always be disabled.
> If you want to use static keys, you need to refresh them in some place
> that it called regularly.
No you don't. I'm assuming if someone enables 'track_peak_rq_based_ios'
they know what they are doing.
But I'm open to suggestions on a more appropriate hook to be catching
the update to track_peak_rq_based_ios.
More information about the dm-devel
mailing list