lkml.org 
[lkml]   [2015]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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..


\
 
 \ /
  Last update: 2015-03-26 20:01    [W:0.095 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site