[dm-devel] [patch 4/4] dm-writecache: use new API for flushing
Mikulas Patocka
mpatocka at redhat.com
Sun Jun 3 15:03:13 UTC 2018
On Wed, 30 May 2018, Mike Snitzer wrote:
> On Wed, May 30 2018 at 10:46P -0400,
> Mikulas Patocka <mpatocka at redhat.com> wrote:
>
> >
> >
> > On Wed, 30 May 2018, Mike Snitzer wrote:
> >
> > > > > Fine I'll deal with it. reordering the fields eliminated holes in the
> > > > > structure and reduced struct members spanning cache lines.
> > > >
> > > > And what about this?
> > > > #define WC_MODE_PMEM(wc) ((wc)->pmem_mode)
> > > >
> > > > The code that I had just allowed the compiler to optimize out
> > > > persistent-memory code if we have DM_WRITECACHE_ONLY_SSD defined - and you
> > > > deleted it.
> > > >
> > > > Most architectures don't have persistent memory and the dm-writecache
> > > > driver could work in ssd-only mode on them. On these architectures, I
> > > > define
> > > > #define WC_MODE_PMEM(wc) false
> > > > - and the compiler will just automatically remove the tests for that
> > > > condition and the unused branch. It does also eliminate unused static
> > > > functions.
> > >
> > > This level of microoptimization can be backfilled. But as it was, there
> > > were too many #defines. And I'm really not concerned with eliminating
> > > unused static functions for this case.
> >
> > I don't see why "too many defines" would be a problem.
> >
> > If I compile it with and without pmem support, the difference is
> > 15kB-vs-12kB. If we look at just one function (writecache_map), the
> > difference is 1595 bytes - vs - 1280 bytes. So, it produces real savings
> > in code size.
> >
> > The problem with performance is not caused a condition that always jumps
> > the same way (that is predicted by the CPU and it causes no delays in the
> > pipeline) - the problem is that a bigger function consumes more i-cache.
> > There is no reason to include code that can't be executed.
>
> Please double check you see the reduced code size you're expecting using
> the latest dm-writecache.c in linux-dm.git's dm-4.18 branch.
>
> Thanks,
> Mike
I checked that - it's OK.
Mikulas
More information about the dm-devel
mailing list