From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752238AbcFNPlg (ORCPT ); Tue, 14 Jun 2016 11:41:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45733 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751320AbcFNPle (ORCPT ); Tue, 14 Jun 2016 11:41:34 -0400 Date: Tue, 14 Jun 2016 11:41:31 -0400 From: Mike Snitzer To: Jeff Moyer Cc: "Kani, Toshimitsu" , "axboe@kernel.dk" , "linux-nvdimm@lists.01.org" , "linux-kernel@vger.kernel.org" , "linux-raid@vger.kernel.org" , "dm-devel@redhat.com" , "viro@zeniv.linux.org.uk" , "dan.j.williams@intel.com" , "ross.zwisler@linux.intel.com" , "agk@redhat.com" Subject: Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices Message-ID: <20160614154131.GB25876@redhat.com> References: <1465856497-19698-1-git-send-email-toshi.kani@hpe.com> <1465861755.3504.185.camel@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 14 Jun 2016 15:41:33 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 14 2016 at 9:50am -0400, Jeff Moyer wrote: > "Kani, Toshimitsu" writes: > > >> I had dm-linear and md-raid0 support on my list of things to look at, > >> did you have raid0 in your plans? > > > > Yes, I hope to extend further and raid0 is a good candidate.    > > dm-flakey would allow more xfstests test cases to run. I'd say that's > more important than linear or raid0. ;-) Regardless of which target(s) grow DAX support the most pressing initial concern is getting the DM device stacking correct. And verifying that IO that cross pmem device boundaries are being properly split by DM core (via drivers/md/dm.c:__split_and_process_non_flush()'s call to max_io_len). My hope is to nail down the DM core and its dependencies in block etc. Doing so in terms of dm-linear doesn't seem like wasted effort considering you told me it'd be useful to have for pmem devices. > Also, the next step in this work is to then decide how to determine on > what numa node an LBA resides. We had discussed this at a prior > plumbers conference, and I think the consensus was to use xattrs. > Toshi, do you also plan to do that work? How does the associated NUMA node relate to this? Does the DM requests_queue need to be setup to only allocate from the NUMA node the pmem device is attached to? I recently added support for this to DM. But there will likely be some code need to propagate the NUMA node id accordingly. Mike