Re: [PATCH tip/core/rcu 0/20] Miscellaneous fixes for 4.11

; 17. Fix comment in rcu_organize_nocb_kthreads(), which no longer > spawns kthreads. > > 18. Clarify comments about when llist locking is needed, courtesy > of Joel Fernandes. > > 19. Eliminate unused expedited_normal counter. > > 20. Add lockdep checks to synchronous expedited primitives. I replied to patches 2, 8, 10, and 11 with comments. For the rest: Reviewed-by: Josh Triplett

Re: [PATCH tip/core/rcu 10/20] rcu: Add functions to test for trivial grace periods

On Sat, Jan 14, 2017 at 01:13:11AM -0800, Paul E. McKenney wrote: > Under some circumstances, RCU grace periods are zero cost. For > RCU-preempt, this is the case during boot, and for RCU-bh and RCU-sched, > this is the case if there is only one CPU. This means that RCU users > might wish to

Re: [PATCH tip/core/rcu 10/20] rcu: Add functions to test for trivial grace periods

On Sat, Jan 14, 2017 at 01:13:11AM -0800, Paul E. McKenney wrote: > Under some circumstances, RCU grace periods are zero cost. For > RCU-preempt, this is the case during boot, and for RCU-bh and RCU-sched, > this is the case if there is only one CPU. This means that RCU users > might wish to

Re: [PATCH tip/core/rcu 08/20] rcu: Add long-term CPU kicking

Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com> Could you please reverse the order of patches 7 and 8, so that unnecessary splats don't occur between the two? For the patch itself: Reviewed-by: Josh Triplett <j...@joshtriplett.org> > kernel/rcu/tree.c | 7 +++ > 1

Re: [PATCH tip/core/rcu 08/20] rcu: Add long-term CPU kicking

gned-off-by: Paul E. McKenney Could you please reverse the order of patches 7 and 8, so that unnecessary splats don't occur between the two? For the patch itself: Reviewed-by: Josh Triplett > kernel/rcu/tree.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --gi

Re: [PATCH tip/core/rcu 02/20] lockdep: Make RCU suspicious-access splats use pr_err

On Sat, Jan 14, 2017 at 01:13:03AM -0800, Paul E. McKenney wrote: > This commit switches RCU suspicious-access splats use pr_err() > instead of the current INFO printk()s. This change makes it easier > to automatically classify splats. > > Reported-by: Dmitry Vyukov >

Re: [PATCH tip/core/rcu 02/20] lockdep: Make RCU suspicious-access splats use pr_err

On Sat, Jan 14, 2017 at 01:13:03AM -0800, Paul E. McKenney wrote: > This commit switches RCU suspicious-access splats use pr_err() > instead of the current INFO printk()s. This change makes it easier > to automatically classify splats. > > Reported-by: Dmitry Vyukov > Signed-off-by: Paul E.

Re: [PATCH tip/core/rcu 0/6] Dynticks updates for 4.11

cu_qs() state less often to reduce GP overhead. > > 6.Adjust FQS offline checks for exact online-CPU detection. I replied to patches 1 and 3 with feedback. For patches 2 and 4-6: Reviewed-by: Josh Triplett <j...@joshtriplett.org> >

Re: [PATCH tip/core/rcu 0/6] Dynticks updates for 4.11

cu_qs() state less often to reduce GP overhead. > > 6.Adjust FQS offline checks for exact online-CPU detection. I replied to patches 1 and 3 with feedback. For patches 2 and 4-6: Reviewed-by: Josh Triplett >

Re: [PATCH tip/core/rcu 3/6] rcu: Abstract dynticks extended quiescent state enter/exit operations

r() function, and > the same but with exit checks in a new rcu_dynticks_eqs_exit() function. > This abstraction will ease changes to the ->dynticks counter operation. > > Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com> A couple of comments below. With those address

Re: [PATCH tip/core/rcu 3/6] rcu: Abstract dynticks extended quiescent state enter/exit operations

r() function, and > the same but with exit checks in a new rcu_dynticks_eqs_exit() function. > This abstraction will ease changes to the ->dynticks counter operation. > > Signed-off-by: Paul E. McKenney A couple of comments below. With those addressed: Reviewed-by: Josh Triplett

Re: [PATCH tip/core/rcu 1/6] rcu: Abstract the dynticks momentary-idle operation

On Sat, Jan 14, 2017 at 12:54:40AM -0800, Paul E. McKenney wrote: > This commit is the first step towards full abstraction of all accesses to > the ->dynticks counter, implementing the previously open-coded atomic add > of two in a new rcu_dynticks_momentary_idle() function. This abstraction >

Re: [PATCH tip/core/rcu 1/6] rcu: Abstract the dynticks momentary-idle operation

On Sat, Jan 14, 2017 at 12:54:40AM -0800, Paul E. McKenney wrote: > This commit is the first step towards full abstraction of all accesses to > the ->dynticks counter, implementing the previously open-coded atomic add > of two in a new rcu_dynticks_momentary_idle() function. This abstraction >

Re: [PATCH tip/core/rcu 0/9] Torture-test changes for 4.11

arly. > > 7.Update RCU test scenario documentation. > > 8.Fix potential memory leak with rw lock test, courtesy of Yang Shi. > > 9.Enable DEBUG_OBJECTS_RCU_HEAD for Tiny RCU, you guessed it, to > make sure that this case is regularly tested. Reviewed-by: Josh Triplett <j...@joshtriplett.org>

Re: [PATCH tip/core/rcu 0/9] Torture-test changes for 4.11

arly. > > 7.Update RCU test scenario documentation. > > 8.Fix potential memory leak with rw lock test, courtesy of Yang Shi. > > 9.Enable DEBUG_OBJECTS_RCU_HEAD for Tiny RCU, you guessed it, to > make sure that this case is regularly tested. Reviewed-by: Josh Triplett

Re: [PATCH tip/core/rcu 0/5] Documentation updates for 4.11

Update control-dependencies section of memory-barriers.txt. > > 4.Update data-structures documentation to note that quick-quiz > answers are now inline. > > 5.Add rcutree.rcu_kick_kthreads to kernel-parameters.txt. Reviewed-by: Josh Triplett <j...@joshtriplett.org>

Re: [PATCH tip/core/rcu 0/5] Documentation updates for 4.11

Update control-dependencies section of memory-barriers.txt. > > 4.Update data-structures documentation to note that quick-quiz > answers are now inline. > > 5.Add rcutree.rcu_kick_kthreads to kernel-parameters.txt. Reviewed-by: Josh Triplett

Re: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on

On Wed, Dec 14, 2016 at 10:11:19AM +0100, Arnd Bergmann wrote: > On Wednesday, December 14, 2016 9:58:53 AM CET Geert Uytterhoeven wrote: > > > > > > --- a/drivers/char/Kconfig > > > +++ b/drivers/char/Kconfig > > > @@ -589,10 +589,13 @@ config TELCLOCK > > > controlling the behavior of

Re: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on

On Wed, Dec 14, 2016 at 10:11:19AM +0100, Arnd Bergmann wrote: > On Wednesday, December 14, 2016 9:58:53 AM CET Geert Uytterhoeven wrote: > > > > > > --- a/drivers/char/Kconfig > > > +++ b/drivers/char/Kconfig > > > @@ -589,10 +589,13 @@ config TELCLOCK > > > controlling the behavior of

Re: /drivers/char/Kconfig Bug Kernel Patch

> From c4a21c2ac0c587094000a3daeb13eec6056dc63f Mon Sep 17 00:00:00 2001 > From: Max > Date: Fri, 9 Dec 2016 15:16:47 -0800 > Subject: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on > > Without a bool string present, using "# CONFIG_DEVPORT is not set" in >

Re: /drivers/char/Kconfig Bug Kernel Patch

> From c4a21c2ac0c587094000a3daeb13eec6056dc63f Mon Sep 17 00:00:00 2001 > From: Max > Date: Fri, 9 Dec 2016 15:16:47 -0800 > Subject: [PATCH] char: lack of bool string made CONFIG_DEVPORT always on > > Without a bool string present, using "# CONFIG_DEVPORT is not set" in > defconfig files would

Re: [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays

On Mon, Nov 14, 2016 at 10:44:21AM -0800, Paul E. McKenney wrote: > On Mon, Nov 14, 2016 at 09:21:10AM -0800, Josh Triplett wrote: > > On Mon, Nov 14, 2016 at 08:57:11AM -0800, Paul E. McKenney wrote: > > > Although rcutorture will occasionally do a 50-millisecond grace-

Re: [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays

On Mon, Nov 14, 2016 at 10:44:21AM -0800, Paul E. McKenney wrote: > On Mon, Nov 14, 2016 at 09:21:10AM -0800, Josh Triplett wrote: > > On Mon, Nov 14, 2016 at 08:57:11AM -0800, Paul E. McKenney wrote: > > > Although rcutorture will occasionally do a 50-millisecond grace-

Re: [PATCH tip/core/rcu 0/2] Torture-test changes for 4.10

On Mon, Nov 14, 2016 at 09:59:24AM -0800, Paul E. McKenney wrote: > Hello! > > This series contains a couple of torture-test changes: > > 1.Remove obsolete files from the rcutorture .gitignore file. > > 2.Prevent the --jitter flag from delaying --build-only run

Re: [PATCH tip/core/rcu 0/2] Torture-test changes for 4.10

On Mon, Nov 14, 2016 at 09:59:24AM -0800, Paul E. McKenney wrote: > Hello! > > This series contains a couple of torture-test changes: > > 1.Remove obsolete files from the rcutorture .gitignore file. > > 2.Prevent the --jitter flag from delaying --build-only run

Re: [PATCH tip/core/rcu 0/7] Miscellaneous fixes for 4.10

o avoid > sending needless IPIs. > > 7.Don't kick CPUs unless there is grace-period activity currently > in progress. I replied to patches 5 and 6 with comments. For 1-4 and 7: Reviewed-by: Josh Triplett <j...@joshtriplett.org>

Re: [PATCH tip/core/rcu 0/7] Miscellaneous fixes for 4.10

o avoid > sending needless IPIs. > > 7.Don't kick CPUs unless there is grace-period activity currently > in progress. I replied to patches 5 and 6 with comments. For 1-4 and 7: Reviewed-by: Josh Triplett

Re: [PATCH tip/core/rcu 6/7] rcu: Make expedited grace periods recheck dyntick idle state

On Mon, Nov 14, 2016 at 08:57:12AM -0800, Paul E. McKenney wrote: > Expedited grace periods check dyntick-idle state, and avoid sending > IPIs to idle CPUs, including those running guest OSes, and, on NOHZ_FULL > kernels, nohz_full CPUs. However, the kernel has been observed checking > a CPU

Re: [PATCH tip/core/rcu 6/7] rcu: Make expedited grace periods recheck dyntick idle state

On Mon, Nov 14, 2016 at 08:57:12AM -0800, Paul E. McKenney wrote: > Expedited grace periods check dyntick-idle state, and avoid sending > IPIs to idle CPUs, including those running guest OSes, and, on NOHZ_FULL > kernels, nohz_full CPUs. However, the kernel has been observed checking > a CPU

Re: [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays

to identify whether or not a given run contained a long-delay read. > This commit therefore inserts a trace_rcu_torture_read() event to flag > runs containing long delays. > > Signed-off-by: Paul E. McKenney <paul...@linux.vnet.ibm.com> A couple of apparent typos below. With

Re: [PATCH tip/core/rcu 5/7] torture: Trace long read-side delays

to identify whether or not a given run contained a long-delay read. > This commit therefore inserts a trace_rcu_torture_read() event to flag > runs containing long delays. > > Signed-off-by: Paul E. McKenney A couple of apparent typos below. With those fixed: Reviewed-by: Josh Tri

Re: [PATCH 0/2] Support compiling out the prctl syscall

On Wed, Nov 09, 2016 at 01:26:53AM +0100, Arnd Bergmann wrote: > On Tuesday, November 8, 2016 4:17:47 PM CET Josh Triplett wrote: > > Some embedded systems can do without the prctl syscall, saving some space. > > > > This also avoids regular increases in tinyconfig size as pe

Re: [PATCH 0/2] Support compiling out the prctl syscall

On Wed, Nov 09, 2016 at 01:26:53AM +0100, Arnd Bergmann wrote: > On Tuesday, November 8, 2016 4:17:47 PM CET Josh Triplett wrote: > > Some embedded systems can do without the prctl syscall, saving some space. > > > > This also avoids regular increases in tinyconfig size as pe

Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

On November 8, 2016 4:56:54 PM PST, Kees Cook <keesc...@chromium.org> wrote: >On Tue, Nov 8, 2016 at 4:47 PM, Josh Triplett <j...@joshtriplett.org> >wrote: >> On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote: >>> On Tue, Nov 8, 2016 at 4:18 PM, Josh Triple

Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

On November 8, 2016 4:56:54 PM PST, Kees Cook wrote: >On Tue, Nov 8, 2016 at 4:47 PM, Josh Triplett >wrote: >> On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote: >>> On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett > wrote: >>> > Some embedded syst

Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote: > On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > Some embedded systems can do without the prctl syscall, saving some > > space. > > > > This also avoids regular increases

Re: [PATCH 2/2] kernel: Support compiling out the prctl syscall

On Tue, Nov 08, 2016 at 04:40:02PM -0800, Kees Cook wrote: > On Tue, Nov 8, 2016 at 4:18 PM, Josh Triplett wrote: > > Some embedded systems can do without the prctl syscall, saving some > > space. > > > > This also avoids regular increases in tinyconfig size as peopl

[PATCH 2/2] kernel: Support compiling out the prctl syscall

1241 - -1241 Total: Before=1902583, After=1900440, chg -0.11% Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- init/Kconfig| 12 kernel/Makefile | 3 ++- kernel/sys_ni.c | 1 + 3 files changed, 15 insertions(+), 1 deletion(-) diff

[PATCH 2/2] kernel: Support compiling out the prctl syscall

1241 - -1241 Total: Before=1902583, After=1900440, chg -0.11% Signed-off-by: Josh Triplett --- init/Kconfig| 12 kernel/Makefile | 3 ++- kernel/sys_ni.c | 1 + 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/init/Kconfig b/init

[PATCH 1/2] kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c

This prepares for making prctl optional. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- kernel/Makefile | 2 +- kernel/prctl.c | 684 +- kernel/sys.c| 672 + 3 files change

[PATCH 0/2] Support compiling out the prctl syscall

source file, kernel/prctl.c, to allow making it optional via the Makefile without any ifdefs. The second patch adds the Kconfig option to make prctl optional. Josh Triplett (2): kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c kernel: Support compiling out the prctl

[PATCH 1/2] kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c

This prepares for making prctl optional. Signed-off-by: Josh Triplett --- kernel/Makefile | 2 +- kernel/prctl.c | 684 +- kernel/sys.c| 672 + 3 files changed, 685 insertions(+), 673

[PATCH 0/2] Support compiling out the prctl syscall

source file, kernel/prctl.c, to allow making it optional via the Makefile without any ifdefs. The second patch adds the Kconfig option to make prctl optional. Josh Triplett (2): kernel: Move prctl and helpers from kernel/sys.c to new kernel/prctl.c kernel: Support compiling out the prctl

Re: [PATCH v3 2/4] kconfig: regenerate *.c_shipped files after previous changes

On Mon, Nov 07, 2016 at 05:41:38PM -0500, Nicolas Pitre wrote: > On Mon, 7 Nov 2016, Josh Triplett wrote: > > > [snipping large patch] > > > > One suggestion that might make this patch easier to review: you might > > consider first regenerating the unc

Re: [PATCH v3 2/4] kconfig: regenerate *.c_shipped files after previous changes

On Mon, Nov 07, 2016 at 05:41:38PM -0500, Nicolas Pitre wrote: > On Mon, 7 Nov 2016, Josh Triplett wrote: > > > [snipping large patch] > > > > One suggestion that might make this patch easier to review: you might > > consider first regenerating the unc

Re: [PATCH v3 2/4] kconfig: regenerate *.c_shipped files after previous changes

[snipping large patch] One suggestion that might make this patch easier to review: you might consider first regenerating the unchanged parser with Bison 3.0.4, then regenerating it again after the "imply" change. I think that'd eliminate quite a lot of noise in this patch. - Josh Triplett

Re: [PATCH v3 2/4] kconfig: regenerate *.c_shipped files after previous changes

[snipping large patch] One suggestion that might make this patch easier to review: you might consider first regenerating the unchanged parser with Bison 3.0.4, then regenerating it again after the "imply" change. I think that'd eliminate quite a lot of noise in this patch. - Josh Triplett

Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default

On Mon, Nov 07, 2016 at 10:05:13AM -0800, Paul E. McKenney wrote: > On Mon, Nov 07, 2016 at 09:35:46AM -0800, Josh Triplett wrote: > > On Mon, Nov 07, 2016 at 06:30:30PM +0100, Sebastian Andrzej Siewior wrote: > > > On 2016-11-07 12:19:39 [-0500], Steven Rostedt wrot

Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default

On Mon, Nov 07, 2016 at 10:05:13AM -0800, Paul E. McKenney wrote: > On Mon, Nov 07, 2016 at 09:35:46AM -0800, Josh Triplett wrote: > > On Mon, Nov 07, 2016 at 06:30:30PM +0100, Sebastian Andrzej Siewior wrote: > > > On 2016-11-07 12:19:39 [-0500], Steven Rostedt wrot

Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default

On Mon, Nov 07, 2016 at 06:30:30PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-11-07 12:19:39 [-0500], Steven Rostedt wrote: > > I agree, but if this creates a boot time regression in large machines, > > it may not be warranted. > > > > I know Linus usually doesn't like options with default

Re: [PATCH] rcu: update: make RCU_EXPEDITE_BOOT default

On Mon, Nov 07, 2016 at 06:30:30PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-11-07 12:19:39 [-0500], Steven Rostedt wrote: > > I agree, but if this creates a boot time regression in large machines, > > it may not be warranted. > > > > I know Linus usually doesn't like options with default

Re: [Ksummit-discuss] Including images on Sphinx documents

On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote: > 2) add an Sphinx extension that would internally call ImageMagick and/or >inkscape to convert the bitmap; This seems sensible; Sphinx should directly handle the source format we want to use for images/diagrams. > 3) if

Re: [Ksummit-discuss] Including images on Sphinx documents

On Mon, Nov 07, 2016 at 07:55:24AM -0200, Mauro Carvalho Chehab wrote: > 2) add an Sphinx extension that would internally call ImageMagick and/or >inkscape to convert the bitmap; This seems sensible; Sphinx should directly handle the source format we want to use for images/diagrams. > 3) if

Re: [Ksummit-discuss] Including images on Sphinx documents

mage conversion. Please don't require --shell-escape as part of the TeX workflow. If LaTeX can't handle the desired image format natively, it needs conversion in advance. - Josh Triplett

Re: [Ksummit-discuss] Including images on Sphinx documents

mage conversion. Please don't require --shell-escape as part of the TeX workflow. If LaTeX can't handle the desired image format natively, it needs conversion in advance. - Josh Triplett

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

n't use a user namespace to cheat and manufacture more users to get more quota when talking to something *outside* that namespace. - Josh Triplett

Re: [RFC v1 00/14] Bus1 Kernel Message Bus

n't use a user namespace to cheat and manufacture more users to get more quota when talking to something *outside* that namespace. - Josh Triplett

Re: [PATCH 0/4] make POSIX timers optional with some Kconfig help

es across three subsystems for potential > upstream merging needs to be figured out. This looks good to me, and I like the new "imply" approach. I'd still like to see a more general solution for reporting the use of compiled-out syscalls, but I don't think that needs to block this patch series. Reviewed-by: Josh Triplett <j...@joshtriplett.org>

Re: [PATCH 0/4] make POSIX timers optional with some Kconfig help

es across three subsystems for potential > upstream merging needs to be figured out. This looks good to me, and I like the new "imply" approach. I'd still like to see a more general solution for reporting the use of compiled-out syscalls, but I don't think that needs to block this patch series. Reviewed-by: Josh Triplett

Re: [PATCH 1/4] kconfig: introduce the "imply" keyword

On Thu, Oct 20, 2016 at 03:52:04PM +0100, Edward Cree wrote: > On 20/10/16 00:42, Nicolas Pitre wrote: > > diff --git a/Documentation/kbuild/kconfig-language.txt > > b/Documentation/kbuild/kconfig-language.txt > > index 069fcb3eef..c96127f648 100644 > > ---

Re: [PATCH 1/4] kconfig: introduce the "imply" keyword

On Thu, Oct 20, 2016 at 03:52:04PM +0100, Edward Cree wrote: > On 20/10/16 00:42, Nicolas Pitre wrote: > > diff --git a/Documentation/kbuild/kconfig-language.txt > > b/Documentation/kbuild/kconfig-language.txt > > index 069fcb3eef..c96127f648 100644 > > ---

Re: [PATCH 3/4] ptp_clock: allow for it to be optional

On Thu, Oct 20, 2016 at 04:06:02PM +0200, Richard Cochran wrote: > On Wed, Oct 19, 2016 at 07:42:52PM -0400, Nicolas Pitre wrote: > > +static inline void ptp_clock_event(struct ptp_clock *ptp, > > + struct ptp_clock_event *event) > > +{ (void)event; } > > Just out of

Re: [PATCH 3/4] ptp_clock: allow for it to be optional

On Thu, Oct 20, 2016 at 04:06:02PM +0200, Richard Cochran wrote: > On Wed, Oct 19, 2016 at 07:42:52PM -0400, Nicolas Pitre wrote: > > +static inline void ptp_clock_event(struct ptp_clock *ptp, > > + struct ptp_clock_event *event) > > +{ (void)event; } > > Just out of

Re: [PATCH] Documentation/RCU: Fix minor typo

On Tue, Oct 18, 2016 at 12:54:03AM -0400, Pranith Kumar wrote: > deference should actually be dereference. > > Signed-off-by: Pranith Kumar <bobby.pr...@gmail.com> Good catch. Reviewed-by: Josh Triplett <j...@joshtriplett.org> > Documentation/RCU/whatisRCU.txt | 2

Re: [PATCH] Documentation/RCU: Fix minor typo

On Tue, Oct 18, 2016 at 12:54:03AM -0400, Pranith Kumar wrote: > deference should actually be dereference. > > Signed-off-by: Pranith Kumar Good catch. Reviewed-by: Josh Triplett > Documentation/RCU/whatisRCU.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: > > I am not sure how/why a firmware loading daemon would be a better > > idea now. What Marc describes that Josh proposed with signals for > > userspcae

Re: [RFC] fs: add userspace critical mounts event support

On Tue, Oct 04, 2016 at 05:12:58PM -0700, Linus Torvalds wrote: > On Tue, Oct 4, 2016 at 5:00 PM, Luis R. Rodriguez wrote: > > I am not sure how/why a firmware loading daemon would be a better > > idea now. What Marc describes that Josh proposed with signals for > > userspcae seems more aligned

Re: [PATCH 1/2] ptp_clock: allow for it to be optional

On Mon, Sep 19, 2016 at 07:04:15PM +0200, Jiri Benc wrote: > On Mon, 19 Sep 2016 10:10:21 -0400 (EDT), Nicolas Pitre wrote: > > --- a/include/linux/ptp_clock_kernel.h > > +++ b/include/linux/ptp_clock_kernel.h > > @@ -207,7 +207,16 @@ int ptp_find_pin(struct ptp_clock *ptp, > > #else > > static

Re: [PATCH 1/2] ptp_clock: allow for it to be optional

On Mon, Sep 19, 2016 at 07:04:15PM +0200, Jiri Benc wrote: > On Mon, 19 Sep 2016 10:10:21 -0400 (EDT), Nicolas Pitre wrote: > > --- a/include/linux/ptp_clock_kernel.h > > +++ b/include/linux/ptp_clock_kernel.h > > @@ -207,7 +207,16 @@ int ptp_find_pin(struct ptp_clock *ptp, > > #else > > static

Re: [PATCH v3) posix-timers: make it configurable

On Thu, Sep 15, 2016 at 05:35:28PM -0400, Nicolas Pitre wrote: > On Thu, 15 Sep 2016, Josh Triplett wrote: > > > On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote: > > > On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote: > > > > This doe

Re: [PATCH v3) posix-timers: make it configurable

On Thu, Sep 15, 2016 at 05:35:28PM -0400, Nicolas Pitre wrote: > On Thu, 15 Sep 2016, Josh Triplett wrote: > > > On Thu, Sep 15, 2016 at 11:07:24PM +0200, Richard Cochran wrote: > > > On Thu, Sep 15, 2016 at 12:58:22PM -0700, John Stultz wrote: > > > > This doe

Re: [PATCH v3) posix-timers: make it configurable

all over the place, then it is going to be > a tough sell. Looking at this particular patch, it does seem a bit much for the ability to have PTP without timers. That doesn't seem like a very likely combination. Handling that in Kconfig seems fine, unless there's a concrete use case for that combination. - Josh Triplett

Re: [PATCH v3) posix-timers: make it configurable

all over the place, then it is going to be > a tough sell. Looking at this particular patch, it does seem a bit much for the ability to have PTP without timers. That doesn't seem like a very likely combination. Handling that in Kconfig seems fine, unless there's a concrete use case for that combination. - Josh Triplett

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, Sep 14, 2016 at 05:05:09PM -0700, Joe Perches wrote: > On Wed, 2016-09-14 at 16:54 -0700, Josh Triplett wrote: > > On Wed, Sep 14, 2016 at 07:56:55PM +0200, Christian Borntraeger wrote: > > > On 09/14/2016 07:51 PM, Joe Perches wrote: > > > > checkpatch ca

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

On Wed, Sep 14, 2016 at 05:05:09PM -0700, Joe Perches wrote: > On Wed, 2016-09-14 at 16:54 -0700, Josh Triplett wrote: > > On Wed, Sep 14, 2016 at 07:56:55PM +0200, Christian Borntraeger wrote: > > > On 09/14/2016 07:51 PM, Joe Perches wrote: > > > > checkpatch ca

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

line option to be used together > > with the -f|--file option to scan any file > > > > Signed-off-by: Joe Perches <j...@perches.com> > > cc: Greg KH <g...@kroah.com> > > cc: Jonathan Corbet <cor...@lwn.net> > > cc: Josh Triplett <

Re: [PATCH] checkpatch: Minimize checkpatch induced patches...

line option to be used together > > with the -f|--file option to scan any file > > > > Signed-off-by: Joe Perches > > cc: Greg KH > > cc: Jonathan Corbet > > cc: Josh Triplett > > cc: Christian Borntraeger > > cc: Theodore Ts'o > > This w

Re: [PATCH v2) posix-timers: make it configurable

On Wed, Sep 14, 2016 at 05:09:53PM -0400, Nicolas Pitre wrote: > On Wed, 14 Sep 2016, Josh Triplett wrote: > > > On Wed, Sep 14, 2016 at 04:46:54PM -0400, Nicolas Pitre wrote: > > > Many embedded systems typically don't need them. This removes about > > > 22KB from

Re: [PATCH v2) posix-timers: make it configurable

On Wed, Sep 14, 2016 at 05:09:53PM -0400, Nicolas Pitre wrote: > On Wed, 14 Sep 2016, Josh Triplett wrote: > > > On Wed, Sep 14, 2016 at 04:46:54PM -0400, Nicolas Pitre wrote: > > > Many embedded systems typically don't need them. This removes about > > > 22KB from

Re: [PATCH v2) posix-timers: make it configurable

However, if others want to see it kept, I won't object too strongly; whoever ends up implementing a common (and optional) version of that infrastructure for all syscalls can fold this into it. - Josh Triplett

Re: [PATCH v2) posix-timers: make it configurable

ee it kept, I won't object too strongly; whoever ends up implementing a common (and optional) version of that infrastructure for all syscalls can fold this into it. - Josh Triplett

Re: [RFC/PATCH] posix-timers: make them configurable

On Fri, Sep 09, 2016 at 09:48:57AM +0200, Richard Cochran wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > Also given many other syscalls take clockids and the backing logic > > isn't really getting removed (probably could cut the dynamic posix > > clocks core with the

Re: [RFC/PATCH] posix-timers: make them configurable

On Fri, Sep 09, 2016 at 09:48:57AM +0200, Richard Cochran wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > Also given many other syscalls take clockids and the backing logic > > isn't really getting removed (probably could cut the dynamic posix > > clocks core with the

Re: [RFC/PATCH] posix-timers: make them configurable

On Thu, Sep 08, 2016 at 07:56:28PM -0400, Nicolas Pitre wrote: > On Thu, 8 Sep 2016, Josh Triplett wrote: > > > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > > On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre <n...@fluxnic.net> wrote: > > > >

Re: [RFC/PATCH] posix-timers: make them configurable

On Thu, Sep 08, 2016 at 07:56:28PM -0400, Nicolas Pitre wrote: > On Thu, 8 Sep 2016, Josh Triplett wrote: > > > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > > On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre wrote: > > > > Small embedded

Re: [RFC/PATCH] posix-timers: make them configurable

On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre wrote: > > Small embedded systems typically don't need them. This removes about > > 16KB from the kernel binary size on ARM when configured out. > > Corresponding

Re: [RFC/PATCH] posix-timers: make them configurable

On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre wrote: > > Small embedded systems typically don't need them. This removes about > > 16KB from the kernel binary size on ARM when configured out. > > Corresponding syscalls are routed to a

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Mon, Aug 29, 2016 at 10:06:18PM +0300, Dan Carpenter wrote: > I would like a couple changes which you know already: > > 1) Get rid of PREFER_ETHER_ADDR_COPY and similar because the people who > send checkpatch.pl fixes aren't qualified to say when it's legal or not > so they sometimes

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Mon, Aug 29, 2016 at 10:06:18PM +0300, Dan Carpenter wrote: > I would like a couple changes which you know already: > > 1) Get rid of PREFER_ETHER_ADDR_COPY and similar because the people who > send checkpatch.pl fixes aren't qualified to say when it's legal or not > so they sometimes

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Mon, Aug 29, 2016 at 11:01:40AM -0700, Joe Perches wrote: > On Mon, 2016-08-29 at 17:46 +, Luck, Tony wrote: > > > > > > 80 columns is simply silly when dealing with either > > > long identifiers or many levels of indentation. > > > > > > One thing that 80 column limit does do is

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Mon, Aug 29, 2016 at 11:01:40AM -0700, Joe Perches wrote: > On Mon, 2016-08-29 at 17:46 +, Luck, Tony wrote: > > > > > > 80 columns is simply silly when dealing with either > > > long identifiers or many levels of indentation. > > > > > > One thing that 80 column limit does do is

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Mon, Aug 29, 2016 at 05:47:59AM -0700, Joe Perches wrote: > I generally don't run it on my own patches, mostly out > of possibly misplaced confidence in my own adherence to > the nominal kernel style.  It sometimes leads to mild > regret over things like whitespace defects. In the specific

Re: [Ksummit-discuss] checkkpatch (in)sanity ?

On Mon, Aug 29, 2016 at 05:47:59AM -0700, Joe Perches wrote: > I generally don't run it on my own patches, mostly out > of possibly misplaced confidence in my own adherence to > the nominal kernel style.  It sometimes leads to mild > regret over things like whitespace defects. In the specific

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > Ben, Mathieu, Dave, do you have jemalloc benchmark numbers with and > > without rseq? (As well as memory usage numbers for the

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Mon, Aug 29, 2016 at 03:16:52PM +, Mathieu Desnoyers wrote: > - On Aug 27, 2016, at 12:22 AM, Josh Triplett j...@joshtriplett.org wrote: > > Ben, Mathieu, Dave, do you have jemalloc benchmark numbers with and > > without rseq? (As well as memory usage numbers for the

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > rseq opens up a whole world of algorithms to userspace – algorithms > that are O(num CPUs) and where one can have an extremely fast fastpath > at the cost of a slower slow path. Many of these algorithms are in use > in the kernel today

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Thu, Aug 25, 2016 at 05:56:25PM +, Ben Maurer wrote: > rseq opens up a whole world of algorithms to userspace – algorithms > that are O(num CPUs) and where one can have an extremely fast fastpath > at the cost of a slower slow path. Many of these algorithms are in use > in the kernel today

Re: [RFC PATCH v8 1/9] Restartable sequences system call

caches per CPU rather than per thread. Also improves locality; that does seem like a good idea. Has anyone written and tested the corresponding changes to a malloc implementation? - Josh Triplett

Re: [RFC PATCH v8 1/9] Restartable sequences system call

caches per CPU rather than per thread. Also improves locality; that does seem like a good idea. Has anyone written and tested the corresponding changes to a malloc implementation? - Josh Triplett

Re: [RFC PATCH v8 1/9] Restartable sequences system call

On Fri, Aug 19, 2016 at 01:23:57PM -0700, Linus Torvalds wrote: > On Fri, Aug 19, 2016 at 1:07 PM, Mathieu Desnoyers > wrote: > > > > Benchmarking various approaches for reading the current CPU number: > > So I'd like to see the benchmarks of something that

<    1   2   3   4   5   6   7   8   9   10   >