On Mon, 13 Jun 2011, Jarod Wilson wrote:
Add a new function pointer to struct clocksource that can optionally be
filled in by clocksources deemed to be high enough resolution to feed
the random number generator entropy pool.
Uurrg.
+ * @entropy: random entropy pool addition function
On Mon, 13 Jun 2011, Venkatesh Pallipadi wrote:
On Mon, Jun 13, 2011 at 3:06 PM, Jarod Wilson ja...@redhat.com wrote:
TSC is high enough resolution that we can use its low-order byte to
stir new data into the random number generator entropy pool.
From what I vaguely remember from years
On Tue, 15 Jul 2014, Tim Chen wrote:
On Tue, 2014-07-15 at 14:59 +0200, Thomas Gleixner wrote:
On Tue, 15 Jul 2014, Peter Zijlstra wrote:
On Tue, Jul 15, 2014 at 11:50:45AM +0200, Peter Zijlstra wrote:
So you already have an idle notifier (which is x86 only, we should fix
that I
On Thu, 19 Jan 2017, Denys Vlasenko wrote:
> A lot of asm-optimized routines in arch/x86/crypto/ keep its
> constants in .data. This is wrong, they should be on .rodata.
>
> Mnay of these constants are the same in different modules.
> For example, 128-bit shuffle mask
On Wed, 9 Nov 2016, Russell King - ARM Linux wrote:
> Please include Thomas in this.
Thanks!
> On Wed, Nov 09, 2016 at 10:46:21AM +0200, Horia Geantă wrote:
> > This reverts commit 66d2e2028091a074aa1290d2eeda5ddb1a6c329c.
> >
> > Quoting from Russell's findings:
> >
On Thu, 10 Nov 2016, Thomas Gleixner wrote:
> > > which corresponds to an 8% slowdown for the threaded IRQ case. So,
> > > tasklets are indeed faster than threaded IRQs.
Forgot to say, that this should be:
So, tasklets are indeed faster than threaded IRQs for this par
for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.
Replace it by using work_on_cpu_safe() which guarantees to run the code on
the requested CPU or to fail in case the CPU is offline.
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Herb
On Sun, 16 Apr 2017, Jason A. Donenfeld wrote:
> I rather like this option of padata, which, since it lives in
> kernel/padata.c and linux/padata.h, should be generic and useful for
> other components. Seems like the ability to allocate it for a
> particular set of worker CPUs and callback CPUs
for that
thread resulting in code executing on the wrong CPU and overwriting the
new affinity setting.
Replace it by using work_on_cpu_safe() which guarantees to run the code on
the requested CPU or to fail in case the CPU is offline.
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
No users outside of padata.c
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Steffen Klassert <steffen.klass...@secunet.com>
Cc: linux-crypto@vger.kernel.org
---
include/linux/padata.h |3 ---
kernel/padata.c| 34 +-
2 files
;
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Steffen Klassert <steffen.klass...@secunet.com>
Cc: linux-crypto@vger.kernel.org
---
kernel/padata.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -913,7
;
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Steffen Klassert <steffen.klass...@secunet.com>
Cc: linux-crypto@vger.kernel.org
---
kernel/padata.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -945,6 +945,8 @@
No users outside of padata.c
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Steffen Klassert <steffen.klass...@secunet.com>
Cc: linux-crypto@vger.kernel.org
---
include/linux/padata.h |3 ---
kernel/padata.c| 32
2 files
On Sun, 21 May 2017, Corentin Labbe wrote:
> Since linux-next-20170517 at least I got the following DEADLOCK warning:
> [4.311614]
> [4.316919] WARNING: possible recursive locking detected
> [4.37] 4.12.0-rc1-next-20170517+ #273 Not
No users outside of padata.c
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Steffen Klassert <steffen.klass...@secunet.com>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Sebastian Siewior <bige...@linutronix.de>
Cc: Steven Rostedt <rost...@goodmis.org>
Cc
15 matches
Mail list logo
