On Thu, Apr 30, 2020 at 06:09:35PM -0700, Josh Triplett wrote:
> On Thu, Apr 30, 2020 at 04:11:18PM -0400, Daniel Jordan wrote:
> > Sometimes the kernel doesn't take full advantage of system memory
> > bandwidth, leading to a single CPU spending excessive time in
> > initialization paths where the
On Thu, Apr 30, 2020 at 05:40:59PM -0400, Pavel Tatashin wrote:
> On Thu, Apr 30, 2020 at 5:31 PM Andrew Morton
> wrote:
> > On Thu, 30 Apr 2020 16:11:18 -0400 Daniel Jordan
> > wrote:
> >
> > > Sometimes the kernel doesn't take full advantage of system memory
> > > bandwidth, leading to a sing
Hi Alex,
On Thu, Apr 30, 2020 at 02:43:28PM -0700, Alexander Duyck wrote:
> On 4/30/2020 1:11 PM, Daniel Jordan wrote:
> > padata will soon divide up pfn ranges between threads when parallelizing
> > deferred init, and deferred_init_maxorder() complicates that by using an
> > opaque index in addit
On Thu, Apr 30, 2020 at 04:11:18PM -0400, Daniel Jordan wrote:
> Sometimes the kernel doesn't take full advantage of system memory
> bandwidth, leading to a single CPU spending excessive time in
> initialization paths where the data scales with memory size.
>
> Multithreading naturally addresses t
On Thu, Apr 30, 2020 at 02:31:31PM -0700, Andrew Morton wrote:
> On Thu, 30 Apr 2020 16:11:18 -0400 Daniel Jordan
> wrote:
> > Sometimes the kernel doesn't take full advantage of system memory
> > bandwidth, leading to a single CPU spending excessive time in
> > initialization paths where the dat
On 4/30/2020 1:11 PM, Daniel Jordan wrote:
padata will soon divide up pfn ranges between threads when parallelizing
deferred init, and deferred_init_maxorder() complicates that by using an
opaque index in addition to start and end pfns. Move the index outside
the function to make splitting the j
On Thu, Apr 30, 2020 at 5:31 PM Andrew Morton wrote:
>
> On Thu, 30 Apr 2020 16:11:18 -0400 Daniel Jordan
> wrote:
>
> > Sometimes the kernel doesn't take full advantage of system memory
> > bandwidth, leading to a single CPU spending excessive time in
> > initialization paths where the data sca
Here are a couple of fixes for warnings introduced with gcc-10.
If you wish to reproduce these, you can find the compiler I used
at [1].
If you like the fixes, please apply them directly into maintainer
trees. I expect that we will also need them to be backported
into stable kernels later.
I disa
gcc-10 complains about using the name of a standard library
function in the kernel, as we are not building with -ffreestanding:
crypto/xts.c:325:13: error: conflicting types for built-in function 'free';
expected 'void(void *)' [-Werror=builtin-declaration-mismatch]
325 | static void free(struc
On Thu, 30 Apr 2020 16:11:18 -0400 Daniel Jordan
wrote:
> Sometimes the kernel doesn't take full advantage of system memory
> bandwidth, leading to a single CPU spending excessive time in
> initialization paths where the data scales with memory size.
>
> Multithreading naturally addresses this
padata allocates per-CPU, per-instance work structs for parallel jobs.
A do_parallel call assigns a job to a sequence number and hashes the
number to a CPU, where the job will eventually run using the
corresponding work.
This approach fit with how padata used to bind a job to each CPU
round-robin,
padata_driver_exit() is unnecessary because padata isn't built as a
module and doesn't exit.
padata's init routine will soon allocate memory, so getting rid of the
exit function now avoids pointless code to free it.
Signed-off-by: Daniel Jordan
---
kernel/padata.c | 6 --
1 file changed, 6
Sometimes the kernel doesn't take full advantage of system memory
bandwidth, leading to a single CPU spending excessive time in
initialization paths where the data scales with memory size.
Multithreading naturally addresses this problem.
Extend padata, a framework that handles many parallel yet s
padata will soon divide up pfn ranges between threads when parallelizing
deferred init, and deferred_init_maxorder() complicates that by using an
opaque index in addition to start and end pfns. Move the index outside
the function to make splitting the job easier, and simplify the code
while at it.
Sometimes the kernel doesn't take full advantage of system memory
bandwidth, leading to a single CPU spending excessive time in
initialization paths where the data scales with memory size.
Multithreading naturally addresses this problem, and this series is the
first step.
It extends padata, a fra
Add Documentation for multithreaded jobs.
Signed-off-by: Daniel Jordan
---
Documentation/core-api/padata.rst | 41 +++
1 file changed, 31 insertions(+), 10 deletions(-)
diff --git a/Documentation/core-api/padata.rst
b/Documentation/core-api/padata.rst
index 9a24c111
Deferred struct page init uses one thread per node, which is a
significant bottleneck at boot for big machines--often the largest.
Parallelize to reduce system downtime.
The maximum number of threads is capped at the number of CPUs on the
node because speedups always improve with additional thread
padata will soon initialize the system's struct pages in parallel, so it
needs to be ready by page_alloc_init_late().
The error return from padata_driver_init() triggers an initcall warning,
so add a warning to padata_init() to avoid silent failure.
Signed-off-by: Daniel Jordan
---
include/linu
- Change title markups;
- Mark literal blocks;
- Use list markups at authors/credits;
- Add blank lines when needed;
- Remove trailing whitespaces.
Signed-off-by: Mauro Carvalho Chehab
---
.../crypto/{api-intro.txt => api-intro.rst} | 186 ++
Documentation/crypto/index.rst
- Place the txt index inside a comment;
- Use title and chapter markups;
- Adjust markups for numbered list;
- Mark literal blocks as such;
- Use tables markup.
- Adjust indentation when needed.
Acked-By: Vinod Koul # dmaengine
Signed-off-by: Mauro Carvalho Chehab
---
.../{async-tx-api.txt => a
Convert this readme file to ReST file format, preserving its
contents as-is as much as possible. The only changes are:
- Added chapter and title markups;
- Added blank lines where needed;
- Added list markups where needed;
- Use a table markup;
- replace markups like `foo' to ``foo``;
- add one ex
This file is almost compatible with ReST. Just minor changes
were needed:
- Adjust document and titles markups;
- Adjust numbered list markups;
- Add a comments markup for the Contents section;
- Add markups for literal blocks.
Acked-by: Jarkko Sakkinen
Signed-off-by: Mauro Carvalho Chehab
---
Manually convert some files from thermal, crypto and misc-devices
to ReST format.
This series is against linux-next 20200430 tag (as I rebased it, in order
to check if some patch were already merged via some other tree),
but it should very likely merge fine against docs-next.
The full series
On Thu, Apr 30, 2020 at 08:26:00AM +, Hadar Gat wrote:
>
> I don't understand if anything need to be fixed before this patch can be
> applied.
> The patch adds dependency on OF, which was missing and is required for the
> cctrng driver.
> (Indeed cctrng compilation passed also without CONFIG_
gcc-10 warns about functions that return a pointer to a stack
variable. In chcr_write_cpl_set_tcb_ulp(), this does not actually
happen, but it's too hard to see for the compiler:
drivers/crypto/chelsio/chcr_ktls.c: In function
'chcr_write_cpl_set_tcb_ulp.constprop':
drivers/crypto/chelsio/chcr_kt
> From: linux-crypto-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Herbert Xu
>
> On Thu, Apr 30, 2020 at 07:39:14AM +, Hadar Gat wrote:
> >
> > Yes, it builds, but it is useless.
>
> But that's the whole point of COMPILE_TEST.
Herbert,
I don't understand if anything need to be
Am Donnerstag, 30. April 2020, 10:13:53 CEST schrieb Wei Yongjun:
Hi Wei,
> Fix to return negative error code -ENOMEM from the kzalloc error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: db07cd26ac6a ("crypto: drbg - add FIPS 140-2 CTRNG for noise source")
> Signed
Fix to return negative error code -ENOMEM from the kzalloc error handling
case instead of 0, as done elsewhere in this function.
Fixes: db07cd26ac6a ("crypto: drbg - add FIPS 140-2 CTRNG for noise source")
Signed-off-by: Wei Yongjun
---
crypto/drbg.c | 4 +++-
1 file changed, 3 insertions(+), 1
On Thu, Apr 30, 2020 at 07:39:14AM +, Hadar Gat wrote:
>
> Yes, it builds, but it is useless.
But that's the whole point of COMPILE_TEST.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org ow...@vger.kernel.org> On Behalf Of Herbert Xu
>
> On Tue, Apr 28, 2020 at 12:26:31PM +, Hadar Gat wrote:
> >
> > I've set COMPILE_TEST but couldn't see any problem.
> > Would you share what doesn't work?
>
> I don't ha
30 matches
Mail list logo
