On Thu, Mar 21, 2019 at 11:03 PM Dexuan Cui wrote:
>
> > From: Dan Williams
> > Sent: Thursday, March 21, 2019 10:37 PM
> >
> > No, I think you misunderstand. Hyper-V implements "function-1",
> > "command-1" support can be emulated. The request is to translate the
> > Hyper-V function-1 payload i
> From: Dan Williams
> Sent: Thursday, March 21, 2019 10:37 PM
>
> No, I think you misunderstand. Hyper-V implements "function-1",
> "command-1" support can be emulated. The request is to translate the
> Hyper-V function-1 payload into the command-1 payload format.
Then, yes, I think so. The fir
On Thu, Mar 21, 2019 at 10:09 PM Dexuan Cui wrote:
>
> > From: Dan Williams
> > Sent: Thursday, March 21, 2019 9:13 PM
> > > ...
> > > Actually, this _is_ an issue for NVDIMM_FAMILY_HYPERV (and the other
> > > families except for NVDIMM_FAMILY_INTEL) : see the kernel function
> > > acpi_nfit_regi
> From: Dan Williams
> Sent: Thursday, March 21, 2019 9:13 PM
> > ...
> > Actually, this _is_ an issue for NVDIMM_FAMILY_HYPERV (and the other
> > families except for NVDIMM_FAMILY_INTEL) : see the kernel function
> > acpi_nfit_register_dimms(), where ND_CMD_SMART is set in the
> > "cmd_mask" only
On Thu, Mar 21, 2019 at 9:06 PM Dexuan Cui wrote:
>
> > From: Dexuan Cui
> > Sent: Thursday, March 21, 2019 7:09 PM
>
> > IMO there are 2 issues in ndctl/monitor.c: filter_dimm():
> >
> > 1. IMO the cmd numbers ND_CMD_SMART (1) and
> > ND_CMD_SMART_THRESHOLD(2) are not really device-neutral. They
> From: Dexuan Cui
> Sent: Thursday, March 21, 2019 7:09 PM
> IMO there are 2 issues in ndctl/monitor.c: filter_dimm():
>
> 1. IMO the cmd numbers ND_CMD_SMART (1) and
> ND_CMD_SMART_THRESHOLD(2) are not really device-neutral. They
> work for ndctl/lib/intel.c and it looks they happen to work fo
Message could not be delivered
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Thu, Mar 21, 2019 at 7:09 PM Dexuan Cui wrote:
[..]
> > That way if the user enters any of the unsupported options, they will
> > just fail normally, and the user will be expected to provide the right
> > options for the environment they know they're running in.
>
> When the user enters any of
> From: Verma, Vishal L
> Sent: Wednesday, March 20, 2019 6:55 PM
> ...
> >
> > -static void filter_dimm(struct ndctl_dimm *dimm, struct util_filter_ctx
> > *fctx)
> > +static bool ndctl_dimm_test_and_enable_notification(struct ndctl_dimm
> *dimm)
> > {
> > - struct monitor_dimm *mdimm;
> > -
On 3/21/19 6:30 PM, Brendan Higgins wrote:
> On Thu, Mar 21, 2019 at 5:22 PM Frank Rowand wrote:
>>
>> On 2/27/19 7:52 PM, Brendan Higgins wrote:
< snip > but thanks for the comments in the snipped section.
>>
>> Thanks for leaving 18/19 and 19/19 off in v4.
>
> Sure, no problem. It was prett
On Thu, Mar 21, 2019 at 6:16 PM Frank Rowand wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Split up the super large test cases of_unittest_find_node_by_name and
> > of_unittest_dynamic into properly sized and defined test cases.
>
> I also still object to this patch.
I figured. Will d
On Thu, Mar 21, 2019 at 6:15 PM Frank Rowand wrote:
>
> On 2/14/19 1:37 PM, Brendan Higgins wrote:
> > Split out a couple of test cases that these features in base.c from the
> > unittest.c monolith. The intention is that we will eventually split out
> > all test cases and group them together base
On Thu, Mar 21, 2019 at 6:10 PM Frank Rowand wrote:
>
> On 2/27/19 11:42 PM, Brendan Higgins wrote:
> > On Tue, Feb 19, 2019 at 10:44 PM Frank Rowand
> > wrote:
> >>
> >> On 2/19/19 7:39 PM, Brendan Higgins wrote:
> >>> On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand
> >>> wrote:
>
> O
On 3/21/19 5:22 PM, Frank Rowand wrote:
> On 2/27/19 7:52 PM, Brendan Higgins wrote:
< snip >
>> Now I know that, hermeticity especially, but other features as well
>> (test suite summary, error on unused test case function, etc) are not
>> actually in KUnit as it is under consideration here. May
> From: Verma, Vishal L
> Sent: Wednesday, March 20, 2019 6:42 PM
> On Wed, 2019-02-20 at 05:11 +, Dexuan Cui wrote:
> > Let's export the family info so we can do some family-specific
> > handling in ndctl/monitor.c for Hyper-V NVDIMM.
>
> s/Let's//
Will fix it.
> > ndctl/lib/libndctl.c
> From: Verma, Vishal L
> Sent: Wednesday, March 20, 2019 6:34 PM
> > ...
> > My feeling is that it's not very good to directly call ndctl_cmd_submit(),
> > but by doing this we don't need to make any change to the common code,
> and
> > I'm unsure if it's good to change the common code just for H
On Thu, Mar 21, 2019 at 5:22 PM Frank Rowand wrote:
>
> On 2/27/19 7:52 PM, Brendan Higgins wrote:
> > On Wed, Feb 20, 2019 at 12:45 PM Frank Rowand
> > wrote:
> >>
> >> On 2/18/19 2:25 PM, Frank Rowand wrote:
> >>> On 2/15/19 2:56 AM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 6:05 P
On 3/4/19 3:01 PM, Brendan Higgins wrote:
> On Thu, Feb 14, 2019 at 1:38 PM Brendan Higgins
> wrote:
>>
>> This patch set proposes KUnit, a lightweight unit testing and mocking
>> framework for the Linux kernel.
>>
>
>
>
>> ## More information on KUnit
>>
>> There is a bunch of documentation ne
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> Split up the super large test cases of_unittest_find_node_by_name and
> of_unittest_dynamic into properly sized and defined test cases.
I also still object to this patch.
-Frank
>
> Signed-off-by: Brendan Higgins
> ---
> drivers/of/base-test.c | 2
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> Split out a couple of test cases that these features in base.c from the
> unittest.c monolith. The intention is that we will eventually split out
> all test cases and group them together based on what portion of device
> tree they test.
I still object t
On 3/21/19 4:33 PM, Brendan Higgins wrote:
> On Thu, Mar 21, 2019 at 3:27 PM Logan Gunthorpe wrote:
>>
>>
>>
>> On 2019-03-21 4:07 p.m., Brendan Higgins wrote:
>>> A couple of points, as for needing CONFIG_PCI; my plan to deal with
>>> that type of thing has been that we would add support for a KU
> From: Verma, Vishal L
> Sent: Wednesday, March 20, 2019 5:23 PM
> ...
> Also on a more general note, the patches in this series don't appear to
> be correctly threaded. Normally, patch emails in a series are replies to
> the first patch (either 1/N or the cover letter), and this allows for
> eas
On 2/27/19 11:42 PM, Brendan Higgins wrote:
> On Tue, Feb 19, 2019 at 10:44 PM Frank Rowand wrote:
>>
>> On 2/19/19 7:39 PM, Brendan Higgins wrote:
>>> On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand
>>> wrote:
On 2/14/19 1:37 PM, Brendan Higgins wrote:
> Add support for aborting/bai
On 12/5/18 3:10 PM, Brendan Higgins wrote:
> On Tue, Dec 4, 2018 at 5:49 AM Rob Herring wrote:
>>
>> On Tue, Dec 4, 2018 at 5:40 AM Frank Rowand wrote:
>>>
>>> Hi Brendan, Rob,
>>>
>>> Pulling a comment from way back in the v1 patch thread:
>>>
>>> On 10/17/18 3:22 PM, Brendan Higgins wrote:
On 2/27/19 7:52 PM, Brendan Higgins wrote:
> On Wed, Feb 20, 2019 at 12:45 PM Frank Rowand wrote:
>>
>> On 2/18/19 2:25 PM, Frank Rowand wrote:
>>> On 2/15/19 2:56 AM, Brendan Higgins wrote:
On Thu, Feb 14, 2019 at 6:05 PM Frank Rowand
wrote:
>
> On 2/14/19 4:56 PM, Brendan Hig
On Thu, Mar 21, 2019 at 1:03 PM Keith Busch wrote:
>
> If a memory node has a preferred migration path to demote cold pages,
> attempt to move those inactive pages to that migration node before
> reclaiming. This will better utilize available memory, provide a faster
> tier than swapping or discar
On Thu, Mar 21, 2019 at 3:27 PM Logan Gunthorpe wrote:
>
>
>
> On 2019-03-21 4:07 p.m., Brendan Higgins wrote:
> > A couple of points, as for needing CONFIG_PCI; my plan to deal with
> > that type of thing has been that we would add support for a KUnit/UML
> > version that is just for KUnit. It wo
On Thu, Mar 21, 2019 at 3:36 PM Keith Busch wrote:
>
> On Thu, Mar 21, 2019 at 02:20:51PM -0700, Zi Yan wrote:
> > 1. The name of “page demotion” seems confusing to me, since I thought it
> > was about large pages
> > demote to small pages as opposite to promoting small pages to THPs. Am I
> > t
On Thu, Mar 21, 2019 at 02:20:51PM -0700, Zi Yan wrote:
> 1. The name of “page demotion” seems confusing to me, since I thought it was
> about large pages
> demote to small pages as opposite to promoting small pages to THPs. Am I the
> only
> one here?
If you have a THP, we'll skip the page migr
On 2019-03-21 4:07 p.m., Brendan Higgins wrote:
> A couple of points, as for needing CONFIG_PCI; my plan to deal with
> that type of thing has been that we would add support for a KUnit/UML
> version that is just for KUnit. It would mock out the necessary bits
> to provide a fake hardware implem
On Wed, Mar 20, 2019 at 6:08 PM Logan Gunthorpe wrote:
>
> Hi,
>
> On 2019-02-14 2:37 p.m., Brendan Higgins wrote:
> > This patch set proposes KUnit, a lightweight unit testing and mocking
> > framework for the Linux kernel.
>
> I haven't followed the entire conversation but I saw the KUnit write-
On Thu, 2019-03-21 at 13:29 -0600, Logan Gunthorpe wrote:
>
> On 2019-03-21 1:13 p.m., Knut Omang wrote:
> > > Nevertheless, I don't really see KTF as a real unit testing framework
> > > for a number of different reasons; you pointed out some below, but I
> > > think the main one being that it req
If a memory node has a preferred migration path to demote cold pages,
attempt to move those inactive pages to that migration node before
reclaiming. This will better utilize available memory, provide a faster
tier than swapping or discarding, and allow such pages to be reused
immediately without IO
Age and reclaim anonymous pages from nodes that have an online migration node
even
if swap is not enabled.
Signed-off-by: Keith Busch
---
include/linux/swap.h | 20
mm/vmscan.c | 10 +-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/include
Refactor unmap_and_move() handling for the new page into a separate
function from locking and preparing the old page.
No functional change here: this is just making it easier to reuse this
part of the page migration from contexts that already locked the old page.
Signed-off-by: Keith Busch
---
Prepare for the kernel to auto-migrate pages to other memory nodes with a
user defined node migration table. A user may create a single target for
each NUMA node to enable the kernel to do NUMA page migrations instead
of simply reclaiming colder pages. A node with no target is a "terminal
node", so
Trace the source and destination node of a page migration to help debug
memory usage.
Signed-off-by: Keith Busch
---
include/trace/events/migrate.h | 26 ++
mm/migrate.c | 1 +
2 files changed, 27 insertions(+)
diff --git a/include/trace/events/migrate
The kernel has recently added support for using persistent memory as
normal RAM:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c221c0b0308fd01d9fb33a16f64d2fd95f8830a4
The persistent memory is hot added to nodes separate from other memory
types, which makes it c
On 2019-03-21 1:13 p.m., Knut Omang wrote:
>> Nevertheless, I don't really see KTF as a real unit testing framework
>> for a number of different reasons; you pointed out some below, but I
>> think the main one being that it requires booting a real kernel on
>> actual hardware;
>
> That depends
On Thu, 2019-03-21 at 09:55 -0700, Brendan Higgins wrote:
> On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe wrote:
> >
> >
> > On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > > Testing drivers, hardware and firmware within production kernels was the
> > > use
> > > case that inspired KTF (Kernel
On 3/21/2019 5:30 PM, Dan Williams wrote:
On Thu, Mar 21, 2019 at 7:27 AM Roberto Sassu wrote:
On 3/21/2019 2:54 PM, Jarkko Sakkinen wrote:
On Mon, Mar 18, 2019 at 04:45:13PM -0700, Dan Williams wrote:
Rather than fail initialization of the trusted.ko module, arrange for
the module to load,
On Thu, Mar 21, 2019 at 8:56 AM Logan Gunthorpe wrote:
>
>
>
> On 2019-03-20 11:23 p.m., Knut Omang wrote:
> > Testing drivers, hardware and firmware within production kernels was the use
> > case that inspired KTF (Kernel Test Framework). Currently KTF is available
> > as a
> > standalone git re
On Thu, Mar 21, 2019 at 7:27 AM Roberto Sassu wrote:
>
> On 3/21/2019 2:54 PM, Jarkko Sakkinen wrote:
> > On Mon, Mar 18, 2019 at 04:45:13PM -0700, Dan Williams wrote:
> >> Rather than fail initialization of the trusted.ko module, arrange for
> >> the module to load, but rely on trusted_instantiat
On 2019-03-20 11:23 p.m., Knut Omang wrote:
> Testing drivers, hardware and firmware within production kernels was the use
> case that inspired KTF (Kernel Test Framework). Currently KTF is available as
> a
> standalone git repository. That's been the most efficient form for us so far,
> as we
On 3/21/2019 2:54 PM, Jarkko Sakkinen wrote:
On Mon, Mar 18, 2019 at 04:45:13PM -0700, Dan Williams wrote:
Rather than fail initialization of the trusted.ko module, arrange for
the module to load, but rely on trusted_instantiate() to fail
trusted-key operations.
Fixes: 240730437deb ("KEYS: trus
On Mon, Mar 18, 2019 at 04:45:13PM -0700, Dan Williams wrote:
> Rather than fail initialization of the trusted.ko module, arrange for
> the module to load, but rely on trusted_instantiate() to fail
> trusted-key operations.
>
> Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure
On Thu, Mar 21, 2019 at 03:45:49PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 19, 2019 at 02:01:44PM -0700, Dan Williams wrote:
> > On Mon, Mar 18, 2019 at 11:18 PM Dan Williams
> > wrote:
> > >
> > > With v5.1-rc1 all the nvdimm sub-system regression tests started failing
> > > because the libn
On Tue, Mar 19, 2019 at 02:01:44PM -0700, Dan Williams wrote:
> On Mon, Mar 18, 2019 at 11:18 PM Dan Williams
> wrote:
> >
> > With v5.1-rc1 all the nvdimm sub-system regression tests started failing
> > because the libnvdimm module failed to load in the qemu-kvm test
> > environment. Critically
On 3/21/2019 2:15 PM, Jarkko Sakkinen wrote:
On Mon, Mar 18, 2019 at 03:35:08PM -0700, Dan Williams wrote:
On Wed, Feb 6, 2019 at 10:30 AM Roberto Sassu wrote:
When crypto agility support will be added to the TPM driver, users of the
driver have to retrieve the allocated banks from chip->allo
On Mon, Mar 18, 2019 at 03:35:08PM -0700, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 10:30 AM Roberto Sassu
> wrote:
> >
> > When crypto agility support will be added to the TPM driver, users of the
> > driver have to retrieve the allocated banks from chip->allocated_banks and
> > use this info
50 matches
Mail list logo
