您好！linux-nvdimm
详，细，课，件，
请，查，阅，附，件，内，容
14:10:29
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Tue, 2018-11-06 at 06:48 -0800, Matthew Wilcox wrote:
> On Tue, Nov 06, 2018 at 03:44:47AM +, Williams, Dan J wrote:
> > Hi Willy,
> >
> > I'm seeing the following warning with v4.20-rc1 and the "dax.sh"
> > test
> > from the ndctl repository:
>
> I'll try to run this myself later today.
Let me ask a question about unit test for acpi_nfit_notify().
The unit test was introduced by commit c14a868a5a14 ("tools/testing/nvdimm:
unit test for acpi_nfit_notify()"), however, it seems that it doesn't
work currently. When I road the nfit_test.ko, I got the following
message.
nfit_test
On Fri, Nov 2, 2018 at 11:44 AM Shuah Khan wrote:
>
> On 10/23/2018 05:57 PM, Brendan Higgins wrote:
> > + * Example:
> > + *
> > + * .. code-block:: c
> > + *
> > + * void add_test_basic(struct test *test)
> > + * {
> > + * TEST_EXPECT_EQ(test, 1, add(1, 0));
> > + *
On Fri, Nov 2, 2018 at 11:23 AM Shuah Khan wrote:
>
> Hi Brendan,
> Framework looks good. I think it would be helpful to include a real test
Great to hear!
> in the patch series to get a feel for how effective it is.
Alright, will do. Rob suggested converting
; >
> > 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 >>):
> >
> >include/net/mac80211.h:1
On Mon, 2018-11-05 at 13:11 -0800, Alexander Duyck wrote:
> +/**
> + * async_schedule_domain - schedule a function for asynchronous execution
> within a certain domain
> + * @func: function to execute asynchronously
> + * @data: data pointer to pass to the function
> + * @domain: the domain
> + *
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote:
> 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
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote:
> 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
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote:
> 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
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote:
> diff --git a/include/linux/device.h b/include/linux/device.h
> index fc7091d436c2..4d9a39769081 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> [ ... ]
> +static inline struct device_driver *dev_get_drv_async(const
are-async_schedule-calls/20181106-093800
> reproduce: make htmldocs
>
> All warnings (new ones prefixed by >>):
>
>include/net/mac80211.h:1001: warning: Function parameter or member
> 'status.is_valid_ack_signal' not described in 'ieee80211_tx_info'
> [ ... ]
Ther
On Mon, 2018-11-05 at 13:12 -0800, Alexander Duyck wrote:
> One change I made in addition is I replaced the use of "bool X:1" to define
> the bitfield to a "u8 X:1" setup in order to resolve some checkpatch
> warnings.
Please use "bool X:1" instead of "u8 X:1". I think it was a bad idea to make
On 2018-11-06 at 22:16 Paolo Bonzini wrote:
> Yes, iter.gfn is the gfn inside the loop and iter.level is the level
> (1=PTE, 2=PDE, ...). iter.level of course is unusable here, similar to
> *levelp in transparent_hugepage_adjust, but you can use iter.gfn and
> gfn_to_hva.
Great, thanks!
On 06/11/2018 22:05, Barret Rhoden wrote:
> On 2018-10-29 at 17:07 Barret Rhoden wrote:
>> Another issue is that kvm_mmu_zap_collapsible_spte() also uses
>> PageTransCompoundMap() to detect huge pages, but we don't have a way to
>> get the HVA easily. Can we just aggressively zap DAX pages
On Tue, Nov 06, 2018 at 10:02:46AM -0800, Dan Williams wrote:
> Just general cautiousness, I'm not opposed to squashing them.
Nah, I can keep them separate - I was just wondering why.
> mce_usable_address() should not have any sensitivity to NVDIMM vs DRAM
> MCEs.
Ok.
Thx.
--
Regards/Gruss,
On Tue, Nov 6, 2018 at 9:53 AM Borislav Petkov wrote:
>
> On Tue, Nov 06, 2018 at 08:20:38AM -0800, Dan Williams wrote:
> > I recommended the split so the fixes can be tracked and / or reverted
> > independently if they cause problems.
>
> Do you have anything concrete in mind that might go wrong
On Tue, Nov 06, 2018 at 08:20:38AM -0800, Dan Williams wrote:
> I recommended the split so the fixes can be tracked and / or reverted
> independently if they cause problems.
Do you have anything concrete in mind that might go wrong or just a
general cautiousness?
Or do you think the hw might not
On Tue, 2018-11-06 at 08:18 -0800, Alexander Duyck wrote:
> On Mon, 2018-11-05 at 17:04 -0800, Bart Van Assche wrote:
> > 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.
>
On Mon, 2018-11-05 at 16:42 -0800, Bart Van Assche wrote:
> 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
>
>
On 11/6/18 9:05 AM, Dan Williams wrote:
> When the platform BIOS is unable to report all the media error records
> it requires the OS to restart the scrub at a prescribed location. The
> driver detects the overflow condition, but then fails to report it to
> the ARS state machine after reaping
On Mon, 2018-11-05 at 16:50 -0800, Bart Van Assche wrote:
> 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,
>
On 2018-11-06 at 11:19 Paolo Bonzini wrote:
> > void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> > {
> > if (!kvm_is_reserved_pfn(pfn)) {
> > struct page *page = pfn_to_page(pfn);
> >
> > if (!PageReserved(page))
> > SetPageDirty(page);
> >
On Tue, Nov 6, 2018 at 6:51 AM Borislav Petkov wrote:
>
> On Thu, Oct 25, 2018 at 06:37:29PM -0600, Vishal Verma wrote:
> > The NFIT machine check handler uses the physical address from the 'mce'
> > structure, and compares it against information in the ACPI NFIT table to
> > determine whether
On Mon, 2018-11-05 at 17:04 -0800, Bart Van Assche wrote:
> 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
When the platform BIOS is unable to report all the media error records
it requires the OS to restart the scrub at a prescribed location. The
driver detects the overflow condition, but then fails to report it to
the ARS state machine after reaping the records. Propagate -ENOSPC
correctly to
On Thu, Oct 25, 2018 at 06:37:29PM -0600, Vishal Verma wrote:
> The NFIT machine check handler uses the physical address from the 'mce'
> structure, and compares it against information in the ACPI NFIT table to
> determine whether that location lies on an NVDIMM. The mce->addr field
> however may
On Tue, Nov 06, 2018 at 03:44:47AM +, Williams, Dan J wrote:
> Hi Willy,
>
> I'm seeing the following warning with v4.20-rc1 and the "dax.sh" test
> from the ndctl repository:
I'll try to run this myself later today.
> I tried to get this test going on -next before the merge window, but
>
Hi all,
I have a question about atomic operations on nvdimm in Linux kernel.
We can use atomic operations in Linux kernel such as atomic_read(),
atomic_write() ...etc., but they don't handle the differences of
endianness. From my understanding, we should pay attention to them when
storing data
On 02/11/2018 21:32, Barret Rhoden wrote:
> One of the other things I noticed was some places in KVM make a
> distinction between kvm_is_reserved_pfn and PageReserved:
>
> void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> {
> if (!kvm_is_reserved_pfn(pfn)) {
> struct page *page =
On 31/10/2018 22:16, Dan Williams wrote:
>> No, please don't. The kvm_is_reserved_pfn() check is for correctness,
>> the page-size check is for optimization. In theory you could have a
>> ZONE_DEVICE area that is smaller than 2MB and thus does not use huge pages.
> To be clear, I was not
31 matches
Mail list logo
