linux-kernel - Re: [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to the device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3b308b65-ab45-9922-abae-b4c25117e388@microsoft.com>
Date:   Wed, 12 Sep 2018 13:44:08 +0000
From:   Pasha Tatashin <Pavel.Tatashin@...rosoft.com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
CC:     "mhocko@...e.com" <mhocko@...e.com>,
        "dave.jiang@...el.com" <dave.jiang@...el.com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "jglisse@...hat.com" <jglisse@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "logang@...tatee.com" <logang@...tatee.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH 4/4] nvdimm: Trigger the device probe on a cpu local to
 the device



On 9/10/18 7:44 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@...el.com>
> 
> This patch is based off of the pci_call_probe function used to initialize
> PCI devices. The general idea here is to move the probe call to a location
> that is local to the memory being initialized. By doing this we can shave
> significant time off of the total time needed for initialization.
> 
> With this patch applied I see a significant reduction in overall init time
> as without it the init varied between 23 and 37 seconds to initialize a 3GB
> node. With this patch applied the variance is only between 23 and 26
> seconds to initialize each node.
> 
> I hope to refine this further in the future by combining this logic into
> the async_schedule_domain code that is already in use. By doing that it
> would likely make this functionality redundant.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@...el.com>

Looks good to me. The previous fast runs were because there we were
getting lucky and executed in the right latency groups, right? Now, we
bound the execution time to be always fast.

Reviewed-by: Pavel Tatashin <pavel.tatashin@...rosoft.com>

Thank you,
Pavel