[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150326183806.GA27181@lst.de>
Date: Thu, 26 Mar 2015 19:38:06 +0100
From: Christoph Hellwig <hch@....de>
To: Boaz Harrosh <boaz@...xistor.com>
Cc: Christoph Hellwig <hch@....de>, linux-nvdimm@...1.01.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
x86@...nel.org, ross.zwisler@...ux.intel.com, axboe@...nel.dk
Subject: Re: another pmem variant V2
On Thu, Mar 26, 2015 at 07:31:03PM +0200, Boaz Harrosh wrote:
> But I hope you are not ignoring my real problem. any two memmap= ranges
> will halt the boot. Specially if they are dis-contiguous.
not the case here, verified it in various cofigurations.
> Also I need the contiguous variant split into two devices because
> they might belong to two NUMA nodes. It is very hard to manage
> if a NUMA crossing is in a middle of a single pmemX device
> The way we like to configure it is that each /dev/pmem belongs to
> a single NUMA node. And in a multy device setup each CPU node
> allocates from "his" pmem device If there is space.
> (And it lets me set application affinity if need to)
The hack below ensures two separate type 12 entries stay separate,
but I'm not sure I really want this. so far it seems like very special
hacks for your very specialized fake-pmem config.
> BTW: Will device mapper let me call ->direct_access()
Right now it doesn't, but it's not hard to add..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists