RE: [ndctl PATCH v13 2/5] ndctl, monitor: add main ndctl monitor configuration file

2018-11-05 Thread qi.f...@fujitsu.com
> > Hi, > > > > I have a future cleanup request. I've just come across, ciniparser > > [1]. It would be great if we could drop the open coded implementation and > > just > use that library. > > We use ccan modules for other portions of ndctl. > > > > [1]:

[mm PATCH v5 2/7] mm: Drop meminit_pfn_in_nid as it is redundant

2018-11-05 Thread Alexander Duyck
As best as I can tell the meminit_pfn_in_nid call is completely redundant. The deferred memory initialization is already making use of for_each_free_mem_range which in turn will call into __next_mem_range which will only return a memory range if it matches the node ID provided assuming it is not

[mm PATCH v5 1/7] mm: Use mm_zero_struct_page from SPARC on all 64b architectures

2018-11-05 Thread Alexander Duyck
This change makes it so that we use the same approach that was already in use on Sparc on all the archtectures that support a 64b long. This is mostly motivated by the fact that 7 to 10 store/move instructions are likely always going to be faster than having to call into a function that is not

[mm PATCH v5 5/7] mm: Move hot-plug specific memory init into separate functions and optimize

2018-11-05 Thread Alexander Duyck
This patch is going through and combining the bits in memmap_init_zone and memmap_init_zone_device that are related to hotplug into a single function called __memmap_init_hotplug. I also took the opportunity to integrate __init_single_page's functionality into this function. In doing so I can get

[mm PATCH v5 3/7] mm: Implement new zone specific memblock iterator

2018-11-05 Thread Alexander Duyck
This patch introduces a new iterator for_each_free_mem_pfn_range_in_zone. This iterator will take care of making sure a given memory range provided is in fact contained within a zone. It takes are of all the bounds checking we were doing in deferred_grow_zone, and deferred_init_memmap. In

[mm PATCH v5 6/7] mm: Add reserved flag setting to set_page_links

2018-11-05 Thread Alexander Duyck
This patch modifies the set_page_links function to include the setting of the reserved flag via a simple AND and OR operation. The motivation for this is the fact that the existing __set_bit call still seems to have effects on performance as replacing the call with the AND and OR can reduce

[mm PATCH v5 0/7] Deferred page init improvements

2018-11-05 Thread Alexander Duyck
This patchset is essentially a refactor of the page initialization logic that is meant to provide for better code reuse while providing a significant improvement in deferred page initialization performance. In my testing on an x86_64 system with 384GB of RAM and 3TB of persistent memory per node

[mm PATCH v5 7/7] mm: Use common iterator for deferred_init_pages and deferred_free_pages

2018-11-05 Thread Alexander Duyck
This patch creates a common iterator to be used by both deferred_init_pages and deferred_free_pages. By doing this we can cut down a bit on code overhead as they will likely both be inlined into the same function anyway. This new approach allows deferred_init_pages to make use of

[driver-core PATCH v5 1/9] workqueue: Provide queue_work_node to queue work near a given NUMA node

2018-11-05 Thread Alexander Duyck
This patch provides a new function queue_work_node which is meant to schedule work on a "random" CPU of the requested NUMA node. The main motivation for this is to help assist asynchronous init to better improve boot times for devices that are local to a specific node. For now we just default to

[driver-core PATCH v5 3/9] device core: Consolidate locking and unlocking of parent and device

2018-11-05 Thread Alexander Duyck
This patch is meant to try and consolidate all of the locking and unlocking of both the parent and device when attaching or removing a driver from a given device. To do that I first consolidated the lock pattern into two functions __device_driver_lock and __device_driver_unlock. After doing that

[driver-core PATCH v5 2/9] async: Add support for queueing on specific NUMA node

2018-11-05 Thread Alexander Duyck
This patch introduces four new variants of the async_schedule_ functions that allow scheduling on a specific NUMA node. The first two functions are async_schedule_near and async_schedule_near_domain which end up mapping to async_schedule and async_schedule_domain but provide NUMA node specific

[driver-core PATCH v5 4/9] driver core: Move async_synchronize_full call

2018-11-05 Thread Alexander Duyck
This patch moves the async_synchronize_full call out of __device_release_driver and into driver_detach. The idea behind this is that the async_synchronize_full call will only guarantee that any existing async operations are flushed. This doesn't do anything to guarantee that a hotplug event that

[driver-core PATCH v5 0/9] Add NUMA aware async_schedule calls

2018-11-05 Thread Alexander Duyck
This patch set provides functionality that will help to improve the locality of the async_schedule calls used to provide deferred initialization. This patch set originally started out with me focused on just the one call to async_schedule_domain in the nvdimm tree that was being used to defer the

[driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-05 Thread Alexander Duyck
This patch adds an additional bit to the device struct named async_probe. This additional bit allows us to guarantee ordering between probe and remove operations. This allows us to guarantee that if we execute a remove operation or a driver load attempt on a given interface it will not attempt to

[driver-core PATCH v5 6/9] driver core: Probe devices asynchronously instead of the driver

2018-11-05 Thread Alexander Duyck
This change makes it so that we probe devices asynchronously instead of the driver. This results in us seeing the same behavior if the device is registered before the driver or after. This way we can avoid serializing the initialization should the driver not be loaded until after the devices have

[driver-core PATCH v5 9/9] libnvdimm: Schedule device registration on node local to the device

2018-11-05 Thread Alexander Duyck
This patch is meant to force the device registration for nvdimm devices to be closer to the actual device. This is achieved by using either the NUMA node ID of the region, or of the parent. By doing this we can have everything above the region based on the region, and everything below the region

[mm PATCH v5 4/7] mm: Initialize MAX_ORDER_NR_PAGES at a time instead of doing larger sections

2018-11-05 Thread Alexander Duyck
This patch adds yet another iterator, for_each_free_mem_range_in_zone_from. It and then uses it to support initializing and freeing pages in groups no larger than MAX_ORDER_NR_PAGES. By doing this we can greatly improve the cache locality of the pages while we do several loops over them in the

[driver-core PATCH v5 7/9] driver core: Attach devices on CPU local to device node

2018-11-05 Thread Alexander Duyck
This change makes it so that we call the asynchronous probe routines on a CPU local to the device node. By doing this we should be able to improve our initialization time significantly as we can avoid having to access the device from a remote node which may introduce higher latency. For example,

[driver-core PATCH v5 8/9] PM core: Use new async_schedule_dev command

2018-11-05 Thread Alexander Duyck
This change makes it so that we use the device specific version of the async_schedule commands to defer various tasks related to power management. By doing this we should see a slight improvement in performance as any device that is sensitive to latency/locality in the setup will now be

扶召|想成为领导的得力助手,却不知道如何才能做得优秀?

2018-11-05 Thread 扶召
linux-nvdimm@lists.01.org 附·件·内·容·请·查·收 ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 5/9] driver core: Establish clear order of operations for deferred probe and remove

2018-11-05 Thread kbuild test robot
Hi Alexander, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on driver-core/master] url: https://github.com/0day-ci/linux/commits/Alexander-Duyck/Add-NUMA-aware-async_schedule-calls/20181106-093800 reproduce: make htmldocs All warnings (new ones prefixed by

(桓扬)每次的业绩为什么总不理想

2018-11-05 Thread 桓扬
您好!linux-nvdimm 详,细,课,件, 请,查,阅,附,件,内,容 8:26:42 ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [driver-core PATCH v5 1/9] workqueue: Provide queue_work_node to queue work near a given NUMA node

2018-11-05 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > +/** > + * workqueue_select_cpu_near - Select a CPU based on NUMA node > + * @node: NUMA node ID that we want to bind a CPU from select? > + /*

fsdax memory error handling regression

2018-11-05 Thread Williams, Dan J
Hi Willy, I'm seeing the following warning with v4.20-rc1 and the "dax.sh" test from the ndctl repository: [ 69.962873] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your own risk [ 69.969522] EXT4-fs (pmem0): mounted filesystem with ordered data mode. Opts: dax [

Re: [driver-core PATCH v5 4/9] driver core: Move async_synchronize_full call

2018-11-05 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > This patch moves the async_synchronize_full call out of > __device_release_driver and into driver_detach. > > The idea behind this is that the async_synchronize_full call will only > guarantee that any existing async operations are

Re: [driver-core PATCH v5 0/9] Add NUMA aware async_schedule calls

2018-11-05 Thread Bart Van Assche
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote: > This patch set provides functionality that will help to improve the > locality of the async_schedule calls used to provide deferred > initialization. Hi Alexander, Is this patch series perhaps available in a public git tree? That would