On 12/16/20 10:25 AM, Verma, Vishal L wrote:
> On Thu, 2020-12-10 at 15:01 +0000, Joao Martins wrote:
>> On 7/21/20 5:49 PM, Joao Martins wrote:
>>> On 7/13/20 5:08 PM, Joao Martins wrote:
>>>> Add a couple tests which exercise the new sysfs based
>>>> interface for Soft-Reserved regions (by EFI/HMAT, or
>>>> efi_fake_mem).
>>>>
>>>> The tests exercise the daxctl orchestration surrounding
>>>> for creating/disabling/destroying/reconfiguring devices.
>>>> Furthermore it exercises dax region space allocation
>>>> code paths particularly:
>>>>
>>>> 1) zeroing out and reconfiguring a dax device from
>>>> its current size to be max available and back to initial
>>>> size
>>>>
>>>> 2) creates devices from holes in the beginning,
>>>> middle of the region.
>>>>
>>>> 3) reconfigures devices in a interleaving fashion
>>>>
>>>> 4) test adjust of the region towards beginning and end
>>>>
>>>> The tests assume you pass a valid efi_fake_mem parameter
>>>> marked as EFI_MEMORY_SP e.g.
>>>>
>>>> efi_fake_mem=112G@16G:0x40000
>>>>
>>>> Naturally it bails out from the test if hmem device driver
>>>> isn't loaded or builtin. If hmem regions are found, only
>>>> region 0 is used, and the others remain untouched.
>>>>
>>>> Signed-off-by: Joao Martins <joao.m.mart...@oracle.com>
>>>
>>> Following your suggestion[0], I added a couple more validations
>>> to this test suite, covering the mappings. So on top of this patch
>>> I added the following snip below the scissors mark. Mainly, I check
>>> that the size calculated by mappingNNNN is the same as advertised by
>>> the sysfs size attribute, thus looping through all the mappings.
>>>
>>> Perhaps it would be enough to have just such validation in setup_dev()
>>> to catch the bug in [0]. But I went ahead and also validated the test
>>> cases where a certain amount of mappings are meant to be created.
>>>
>>> My only worry is the last piece in daxctl_test_adjust() where we might
>>> be tying too much on how a kernel version picks space from the region;
>>> should this logic change in an unforeseeable future (e.g. allowing space
>>> at the beginning to be adjusted). Otherwise, if this no concern, let me
>>> know and I can resend a v3 with the adjustment below.
>>>
>>
>> Ping?
>
> Hi Joao,
>
> Thanks for the patience on these, I've gone through the patches in
> preparation for the next release, and they all look mostly fine. I had a
> few minor fixups - to the documentation and the test (fixup module name,
> and shellcheck complaints). I've appended a diff below of all the fixups
> I added.
>
The adjustments are looking good AFAICT.
> I've also included the patch below for the mapping size validation. I
> think the concern for future kernel layout changes is valid, but if/when
> that happens, we can always come back and relax or adjust the test as
> needed. So for now, I think having a pickier test should be better than
> not having one.
>
Yeah, makes sense.
Thanks!
Joao
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-le...@lists.01.org
