The DM_TYPE_DAX_BIO_BASED dm_queue_mode was introduced to prevent DM
devices that could possibly support DAX from transitioning into DM devices
that cannot support DAX.
For example, the following transition will currently fail:
dm-linear: [fsdax pmem][fsdax pmem] => [fsdax pmem][fsdax raw]
On Mon, May 28, 2018 at 05:38:10PM +0200, Arnd Bergmann wrote:
> The new dm-writecache driver inconditionally uses the dax
unconditionally
> subsystem, leading to link errors in some configurations:
>
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-
Currently device_supports_dax() just checks to see if the QUEUE_FLAG_DAX
flag is set on the device's request queue to decide whether or not the
device supports filesystem DAX. This is insufficient because there are
devices like PMEM namespaces in raw mode which have QUEUE_FLAG_DAX set but
which do
Changes from v1:
* Reworked patches 1 and 2 so that the __bdev_dax_supported() function
stays hidden behind the bdev_dax_supported() wrapper. This is needed
to prevent compilation errors in configs where CONFIG_FS_DAX isn't
defined. (0-day)
* Added Eric's Reviewed-by to patch 1. I did
As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
will fail with link errors in configs where DAX isn't present:
drivers/md/dm-writecache.o: In function `writecache_ctr':
dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_lock'
dm-writecache.c:(.text+0x2004):
On Tue, May 29, 2018 at 02:25:10PM -0700, Darrick J. Wong wrote:
> On Tue, May 29, 2018 at 01:51:01PM -0600, Ross Zwisler wrote:
> > From: Dave Jiang
> >
> > The function return values are confusing with the way the function is
> > named. We expect a true or false return value but it actually ret
From: "Darrick J. Wong"
Change bdev_dax_supported so it takes a bdev parameter. This enables
multi-device filesystems like xfs to check that a dax device can work for
the particular filesystem. Once that's in place, actually fix all the
parts of XFS where we need to be able to distinguish betwe
This stub was added so that we could use dm-snap with DM_TYPE_DAX_BIO_BASED
mode devices. That mode and the transition issues associated with it no
longer exist, so we can remove this dead code.
Signed-off-by: Ross Zwisler
---
drivers/md/dm-snap.c | 8
1 file changed, 8 deletions(-)
d
This stub was added so that we could use dm-error with
DM_TYPE_DAX_BIO_BASED mode devices. That mode and the transition issues
associated with it no longer exist, so we can remove this dead code.
Signed-off-by: Ross Zwisler
---
drivers/md/dm-target.c | 7 ---
1 file changed, 7 deletions(-)
Currently the code in dm_dax_direct_access() only checks whether the target
type has a direct_access() operation defined, not whether the underlying
block devices all support DAX. This latter property can be seen by looking
at whether we set the QUEUE_FLAG_DAX request queue flag when creating the
From: Dave Jiang
The function return values are confusing with the way the function is
named. We expect a true or false return value but it actually returns
0/-errno. This makes the code very confusing. Changing the return values
to return a bool where if DAX is supported then return true and no
On Mon, 28 May 2018, Arnd Bergmann wrote:
> The return type of ACCESS_ONCE is configuration dependent and may be either
> 'int' or 'long int' for the writecache_has_error() macro, so we get a warning
> like this for either format string:
__builtin_expect returns always long, see the GCC docume
The function __builtin_expect returns long type (see the gcc
documentation), and so do macros likely and unlikely. Unfortunatelly, when
CONFIG_PROFILE_ANNOTATED_BRANCHES is selected, the macros likely and
unlikely expand to __branch_check__ and __branch_check__ truncates the
long type to int. This
On Mon, 28 May 2018, Arnd Bergmann wrote:
> The new dm-writecache driver inconditionally uses the dax
> subsystem, leading to link errors in some configurations:
>
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined reference to `dax_read_loc
On Tue, 29 May 2018, Ross Zwisler wrote:
> As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
> will fail with link errors in configs where DAX isn't present:
>
> drivers/md/dm-writecache.o: In function `writecache_ctr':
> dm-writecache.c:(.text+0x1fdc): undefined refere
Hello Mikulas Patocka,
The patch 2105231db61b: "dm: add writecache target" from Mar 8, 2018,
leads to the following static checker warning:
drivers/md/dm-writecache.c:1868 writecache_ctr()
warn: 'wc->dm_io' is an error pointer or valid
drivers/md/dm-writecache.c
1854
1855
On Mon, 28 May 2018, Dan Williams wrote:
> On Mon, May 28, 2018 at 6:32 AM, Mikulas Patocka wrote:
> >
> >
> > On Sat, 26 May 2018, Dan Williams wrote:
> >
> >> On Sat, May 26, 2018 at 12:02 AM, Mikulas Patocka
> >> wrote:
> >> >
> >> >
> >> > On Fri, 25 May 2018, Dan Williams wrote:
> >> >
On Wed, May 30 2018 at 8:22am -0400,
Mikulas Patocka wrote:
>
>
> On Tue, 29 May 2018, Ross Zwisler wrote:
>
> > As reported by Arnd (https://lkml.org/lkml/2018/5/28/1697), dm-writecache
> > will fail with link errors in configs where DAX isn't present:
> >
> > drivers/md/dm-writecache.o: In
On Wed, May 30 2018 at 9:07am -0400,
Mikulas Patocka wrote:
>
>
> On Mon, 28 May 2018, Dan Williams wrote:
>
> > On Mon, May 28, 2018 at 6:32 AM, Mikulas Patocka
> > wrote:
> > >
> > > I measured it (with nvme backing store) and late cache flushing has 12%
> > > better performance than eage
Here I'm sending the current dm-writecache patch.
The per-architecture switch was removed.
Some reported bugs are fixed.
Mikulas
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
In order to reduce locking overhead, I use the spinlock in
swait_queue_head to protect not only the wait queue, but also the list of
events. Consequently, I need to use unlocked functions __prepare_to_swait
and __finish_swait. These functions are declared in the file
include/linux/swait.h, but they
The dm-writecache target.
Signed-off-by: Mikulas Patocka
---
Documentation/device-mapper/writecache.txt | 68
drivers/md/Kconfig | 11
drivers/md/Makefile|1
drivers/md/dm-writecache.c | 2382
The function __builtin_expect returns long type (see the gcc
documentation), and so do macros likely and unlikely. Unfortunatelly, when
CONFIG_PROFILE_ANNOTATED_BRANCHES is selected, the macros likely and
unlikely expand to __branch_check__ and __branch_check__ truncates the
long type to int. This
I use memcpy_flushcache in my persistent memory driver for metadata
updates and it turns out that the overhead of memcpy_flushcache causes 2%
performance degradation compared to "movnti" instruction explicitly coded
using inline assembler.
This patch recognizes memcpy_flushcache calls with constan
On Wed, 30 May 2018, Mike Snitzer wrote:
> That is really great news, can you submit an incremental patch that
> layers ontop of the linux-dm.git 'dm-4.18' branch?
>
> Thanks,
> Mike
I've sent the current version that I have. I fixed the bugs that were
reported here (missing DAX, dm_bufio_cl
On Wed, May 30 2018 at 9:16am -0400,
Mikulas Patocka wrote:
> Here I'm sending the current dm-writecache patch.
> The per-architecture switch was removed.
>
> Some reported bugs are fixed.
I've staged dm-writecache in linux-dm.git's dm-4.18 branch. Please
rebase ontop of that.
In particular,
On Wed, May 30 2018 at 9:21am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > That is really great news, can you submit an incremental patch that
> > layers ontop of the linux-dm.git 'dm-4.18' branch?
> >
> > Thanks,
> > Mike
>
> I've sent the current vers
On Wed, 30 May 2018, Mike Snitzer wrote:
> On Wed, May 30 2018 at 9:21am -0400,
> Mikulas Patocka wrote:
>
> >
> >
> > On Wed, 30 May 2018, Mike Snitzer wrote:
> >
> > > That is really great news, can you submit an incremental patch that
> > > layers ontop of the linux-dm.git 'dm-4.18' br
Dan Williams writes:
> When I read your patch I came away with the impression that ARM had
> not added memcpy_flushcache() yet and you were working around that
> fact. Now that I look, ARM *does* define memcpy_flushcache() and
> you're avoiding it. You use memcpy+arch_wb_pmem where arch_wb_pmem o
On Wed, 30 May 2018, Jeff Moyer wrote:
> Dan Williams writes:
>
> > When I read your patch I came away with the impression that ARM had
> > not added memcpy_flushcache() yet and you were working around that
> > fact. Now that I look, ARM *does* define memcpy_flushcache() and
> > you're avoidi
Jeff Moyer writes:
> Dan Williams writes:
>
>> When I read your patch I came away with the impression that ARM had
>> not added memcpy_flushcache() yet and you were working around that
>> fact. Now that I look, ARM *does* define memcpy_flushcache() and
>> you're avoiding it. You use memcpy+arch_
On Wed, May 30 2018 at 9:33am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > On Wed, May 30 2018 at 9:21am -0400,
> > Mikulas Patocka wrote:
> >
> > >
> > >
> > > On Wed, 30 May 2018, Mike Snitzer wrote:
> > >
> > > > That is really great news, can yo
On Wed, 30 May 2018, Mike Snitzer wrote:
> On Wed, May 30 2018 at 9:33am -0400,
> Mikulas Patocka wrote:
>
> >
> >
> > On Wed, 30 May 2018, Mike Snitzer wrote:
> >
> > > On Wed, May 30 2018 at 9:21am -0400,
> > > Mikulas Patocka wrote:
> > >
> > > >
> > > >
> > > > On Wed, 30 May 201
On Wed, May 30 2018 at 10:09am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > On Wed, May 30 2018 at 9:33am -0400,
> > Mikulas Patocka wrote:
> >
> > >
> > >
> > > On Wed, 30 May 2018, Mike Snitzer wrote:
> > >
> > > > On Wed, May 30 2018 at 9:21am -0
On Wed, 30 May 2018, Mike Snitzer wrote:
> On Wed, May 30 2018 at 10:09am -0400,
> Mikulas Patocka wrote:
>
> >
> >
> > On Wed, 30 May 2018, Mike Snitzer wrote:
> >
> > > On Wed, May 30 2018 at 9:33am -0400,
> > > Mikulas Patocka wrote:
> > >
> > > >
> > > >
> > > > On Wed, 30 May 201
On Wed, May 30, 2018 at 6:07 AM, Mikulas Patocka wrote:
>
>
> On Mon, 28 May 2018, Dan Williams wrote:
>
>> On Mon, May 28, 2018 at 6:32 AM, Mikulas Patocka wrote:
>> >
>> >
>> > On Sat, 26 May 2018, Dan Williams wrote:
>> >
>> >> On Sat, May 26, 2018 at 12:02 AM, Mikulas Patocka
>> >> wrote:
>
This patch removes the per-architecture abstraction.
Only pmem_assign is left, because it is more convenient to use than
memcpy_flushcache (and also, on architectures that don't support
persistent memory, we want to redefine pmem_assign so that it doesn't
flush the cache).
It also fixes a test
On 5/29/18 5:27 PM, Mike Snitzer wrote:
> On Tue, May 29 2018 at 4:09am -0400,
> Christoph Hellwig wrote:
>
>> On Tue, May 29, 2018 at 09:22:40AM +0200, Johannes Thumshirn wrote:
>>> For a "Plan B" we can still use the global knob that's already in
>>> place (even if this reminds me so much abou
On Wed, May 30 2018 at 3:05pm -0400,
Jens Axboe wrote:
> On 5/29/18 5:27 PM, Mike Snitzer wrote:
> > On Tue, May 29 2018 at 4:09am -0400,
> > Christoph Hellwig wrote:
> >
> >> On Tue, May 29, 2018 at 09:22:40AM +0200, Johannes Thumshirn wrote:
> >>> For a "Plan B" we can still use the global
On Wed, May 30, 2018 at 8:58 AM, Dan Williams wrote:
> On Wed, May 30, 2018 at 6:07 AM, Mikulas Patocka wrote:
>>
>>
>> On Mon, 28 May 2018, Dan Williams wrote:
>>
>>> On Mon, May 28, 2018 at 6:32 AM, Mikulas Patocka
>>> wrote:
>>> >
>>> >
>>> > On Sat, 26 May 2018, Dan Williams wrote:
>>> >
>>
On Wed, May 30 2018 at 10:09P -0400,
Mikulas Patocka wrote:
> 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
On Wed, May 30 2018 at 10:46P -0400,
Mikulas Patocka 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?
> > >
42 matches
Mail list logo
