On Fri, Aug 16, 2019 at 10:49:04PM +0200, Thomas Gleixner wrote:
> On Fri, 16 Aug 2019, Joel Fernandes wrote:
> > On Fri, Aug 16, 2019 at 3:19 PM Alan Stern
> > wrote:
> > > On Fri, 16 Aug 2019, Mathieu Desnoyers wrote:
> > >
> > > > If you choose n
On Fri, Aug 16, 2019 at 3:19 PM Alan Stern wrote:
>
> On Fri, 16 Aug 2019, Mathieu Desnoyers wrote:
>
> > If you choose not to use READ_ONCE(), then the "load tearing" issue can
> > cause similar spurious 1 -> 0 -> 1 transitions near 16-bit counter
> > overflow as described above. The "Invented
change log rework!
thanks,
- Joel
> Thanx, Paul
>
> On Wed, Aug 14, 2019 at 12:04:10PM -0400, Joel Fernandes (Google) wrote:
> > A recent discussion about stability and performance systems with
> > kfree_rcu() flooding [1]
On Fri, Aug 16, 2019 at 10:25:29AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 15, 2019 at 10:53:09PM -0400, Joel Fernandes (Google) wrote:
> > This commit fixes the issue.
> >
> > Signed-off-by: Joel Fernandes (Google)
>
> And I am squashing these in
On Fri, Aug 16, 2019 at 09:52:42AM -0700, Paul E. McKenney wrote:
> On Fri, Aug 16, 2019 at 12:24:04PM -0400, Joel Fernandes wrote:
> > On Thu, Aug 15, 2019 at 10:53:11PM -0400, Joel Fernandes (Google) wrote:
> > > I really cannot explain this patch, but without it, the "el
On Thu, Aug 15, 2019 at 10:53:11PM -0400, Joel Fernandes (Google) wrote:
> I really cannot explain this patch, but without it, the "else if" block
> just doesn't execute thus causing the tick's dep mask to not be set and
> causes the tick to be turned off.
>
> I tri
Sometimes I see rcu_urgent_qs is not set. This could be when the last
IPI was a long time ago, however, the grace period just started. Set
rcu_urgent_qs so the tick can indeed not be stopped.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 1 +
1 file changed, 1 insertion
On Thu, Aug 15, 2019 at 10:53:10PM -0400, Joel Fernandes (Google) wrote:
> Sometimes I see rcu_urgent_qs is not set. This could be when the last
> IPI was a long time ago, however, the grace period just started. Set
> rcu_urgent_qs so the tick can indeed be stopped.
Her
Sometimes I see rcu_urgent_qs is not set. This could be when the last
IPI was a long time ago, however, the grace period just started. Set
rcu_urgent_qs so the tick can indeed be stopped.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 1 +
1 file changed, 1 insertion(+)
diff
I really cannot explain this patch, but without it, the "else if" block
just doesn't execute thus causing the tick's dep mask to not be set and
causes the tick to be turned off.
I tried various _ONCE() macros but the only thing that works is this
patch.
Signed-off-by: Joel Fernand
This commit fixes the issue.
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 0512de9ead20..322b1b57967c 100644
--- a/kernel/rcu/tree.c
On Thu, Aug 15, 2019 at 11:39:37AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 15, 2019 at 02:15:00PM -0400, Joel Fernandes wrote:
> > On Thu, Aug 15, 2019 at 10:23:51AM -0700, Paul E. McKenney wrote:
> > > > [snip]
> > > > > > > If so, perhaps that m
On Thu, Aug 15, 2019 at 10:23:51AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 15, 2019 at 11:07:35AM -0400, Joel Fernandes wrote:
> > On Wed, Aug 14, 2019 at 03:05:16PM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > If so, perhaps that monitoring co
nce.
>
> Co-developed-by: Christian Brauner
> Signed-off-by: Christian Brauner
> Signed-off-by: Hridya Valsaraju
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> drivers/android/binderfs.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
h binderfs instance instead of global devices
> being created by the binder driver.
>
> Co-developed-by: Christian Brauner
> Signed-off-by: Christian Brauner
> Signed-off-by: Hridya Valsaraju
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
>
> Changes in v2:
&
h binderfs instance instead of global devices
> being created by the binder driver.
>
> Co-developed-by: Christian Brauner
> Signed-off-by: Christian Brauner
> Signed-off-by: Hridya Valsaraju
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> ---
>
> Changes in v2:
&
On Wed, Aug 14, 2019 at 03:05:16PM -0700, Paul E. McKenney wrote:
[snip]
> > > > Arming a CPU timer could also be an alternative to tick_set_dep_cpu()
> > > > for that.
> > > >
> > > > What do you think?
> > >
> > > Left to itself, RCU would take action only when a given nohz_full
> > >
ase (where I had a nohz full CPU holding up a grace period).
2 comments below:
>
>
> commit 1cb89508804f6f2fdb79a1be032b1932d52318c4
> Author: Paul E. McKenney
> Date: Mon Aug 12 16:14:00 2019 -0700
>
>
On Wed, Aug 14, 2019 at 10:38:17AM -0400, Joel Fernandes wrote:
> On Tue, Aug 13, 2019 at 12:07:38PM -0700, Paul E. McKenney wrote:
[snip]
> > > - * Queue an RCU callback for lazy invocation after a grace period.
> > > - * This will likely be later named somethin
gchul Park
Signed-off-by: Byungchul Park
Signed-off-by: Joel Fernandes (Google)
---
v3->v4: Some corrections by Paul.
Used xchg in places to simplify code.
v2->v3: Just some code comment changes thanks to Byungchul.
RFCv1->PATCH v2: Removed limits on the ->head
is
increased from HZ/50 to HZ/80.
Also, when running the test, please disable CONFIG_DEBUG_PREEMPT and
CONFIG_PROVE_RCU for realistic comparisons with/without batching.
Signed-off-by: Joel Fernandes (Google)
---
.../admin-guide/kernel-parameters.txt | 17 ++
kernel/rcu/rcuperf.c
On Tue, Aug 13, 2019 at 05:34:16PM +0200, Daniel Gruss wrote:
> On 8/13/19 5:29 PM, Jann Horn wrote:
> > On Tue, Aug 13, 2019 at 12:09 PM Michal Hocko wrote:
> >> On Mon 12-08-19 20:14:38, Jann Horn wrote:
> >>> On Wed, Aug 7, 2019 at 7:16 PM Joel F
On Tue, Aug 13, 2019 at 11:14:30AM +0200, Michal Hocko wrote:
> On Mon 12-08-19 10:56:20, Joel Fernandes wrote:
> > On Thu, Aug 08, 2019 at 10:00:44AM +0200, Michal Hocko wrote:
> > > On Wed 07-08-19 17:31:05, Joel Fernandes wrote:
> > > > On Wed, Aug 07, 2019 at 0
On Mon, Aug 12, 2019 at 7:23 PM Paul E. McKenney wrote:
>
> On Mon, Aug 12, 2019 at 11:02:33PM +0200, Frederic Weisbecker wrote:
> > On Fri, Aug 02, 2019 at 08:15:01AM -0700, Paul E. McKenney wrote:
> > > The multi_cpu_stop() function relies on the scheduler to gain control from
> > > whatever is
On Sun, Aug 11, 2019 at 04:35:04PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 10, 2019 at 10:26:58PM -0400, Joel Fernandes wrote:
> > On Sat, Aug 10, 2019 at 11:24:46AM -0700, Paul E. McKenney wrote:
> > > On Sat, Aug 10, 2019 at 12:20:37AM -0400, Joel Fernandes wrote:
>
On Mon, Aug 12, 2019 at 07:10:52PM +0900, Byungchul Park wrote:
> On Sun, Aug 11, 2019 at 04:49:39PM -0700, Paul E. McKenney wrote:
> > Maybe. Note well that I said "potential issue". When I checked a few
> > years ago, none of the uses of rcu_barrier() cared about kfree_rcu().
> > They cared
On Mon, Aug 12, 2019 at 07:02:56AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 11, 2019 at 06:11:11PM -0400, Joel Fernandes (Google) wrote:
> > Properly check if lockdep lock checking is disabled at config time. If
> > so, then lock_is_held() is undefined so don't
On Sat, Aug 10, 2019 at 11:24:46AM -0700, Paul E. McKenney wrote:
> On Sat, Aug 10, 2019 at 12:20:37AM -0400, Joel Fernandes wrote:
> > On Fri, Aug 09, 2019 at 08:38:14PM -0700, Paul E. McKenney wrote:
> > > On Fri, Aug 09, 2019 at 10:42:32PM -0400, Joel Fernandes wrote:
>
On Tue, Aug 06, 2019 at 05:29:15PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 06, 2019 at 05:20:41PM -0400, Joel Fernandes (Google) wrote:
> > This test runs kfree_rcu in a loop to measure performance of the new
> > kfree_rcu, with and without patch.
> >
> > To see
On Fri, Aug 09, 2019 at 08:38:14PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 09, 2019 at 10:42:32PM -0400, Joel Fernandes wrote:
> > On Wed, Aug 07, 2019 at 10:52:15AM -0700, Paul E. McKenney wrote:
> > [snip]
> > > > > > @@ -3459,6 +36
On Fri, Aug 09, 2019 at 08:40:27PM -0700, Paul E. McKenney wrote:
[snip]
> > > In contrast, a heavy duty userspace-driven workload would transition to
> > > and from userspace for each kfree_rcu(), and that would increment the
> > > dyntick-idle count on each transition to and from userspace.
On Wed, Aug 07, 2019 at 10:52:15AM -0700, Paul E. McKenney wrote:
[snip]
> > > > @@ -3459,6 +3645,8 @@ void __init rcu_init(void)
> > > > {
> > > > int cpu;
> > > >
> > > > + kfree_rcu_batch_init();
> > >
> > > What happens if someone does a kfree_rcu() before this point? It
On Fri, Aug 09, 2019 at 01:42:17PM -0700, Paul E. McKenney wrote:
> > Also, I can go back to 500M if I just keep KFREE_DRAIN_JIFFIES at HZ/50. So
> > I
> > am quite happy about that. I think I can declare that the "let list grow
> > indefinitely" design works quite well even with an insanely
On Fri, Aug 09, 2019 at 04:26:45PM -0400, Joel Fernandes wrote:
> On Fri, Aug 09, 2019 at 04:22:26PM -0400, Joel Fernandes wrote:
> > On Fri, Aug 09, 2019 at 09:33:46AM -0700, Paul E. McKenney wrote:
> > > On Fri, Aug 09, 2019 at 11:39:24AM -0400, Joel Fernandes wrote:
> >
On Fri, Aug 09, 2019 at 04:22:26PM -0400, Joel Fernandes wrote:
> > > > o With any of the above, invoke rcu_momentary_dyntick_idle() along
> > > > with cond_resched() in your kfree_rcu() loop. This simulates
> > > > a trip to userspace
On Fri, Aug 09, 2019 at 04:22:26PM -0400, Joel Fernandes wrote:
> On Fri, Aug 09, 2019 at 09:33:46AM -0700, Paul E. McKenney wrote:
> > On Fri, Aug 09, 2019 at 11:39:24AM -0400, Joel Fernandes wrote:
> > > On Fri, Aug 09, 2019 at 08:16:19AM -0700, Paul E. McKenney wrote:
>
On Fri, Aug 09, 2019 at 09:33:46AM -0700, Paul E. McKenney wrote:
> On Fri, Aug 09, 2019 at 11:39:24AM -0400, Joel Fernandes wrote:
> > On Fri, Aug 09, 2019 at 08:16:19AM -0700, Paul E. McKenney wrote:
> > > On Thu, Aug 08, 2019 at 07:30:14PM -0400, Joel Fernandes wrote:
> >
On Fri, Aug 09, 2019 at 09:51:20AM -0700, Paul E. McKenney wrote:
> > > > And of course I forgot to dump out the online CPUs, so I really had no
> > > > idea whether or not all the CPUs were accounted for. I added tracing
> > > > to dump out the online CPUs at the beginning of __stop_cpus() and
On Wed, Aug 07, 2019 at 10:56:57AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 07, 2019 at 06:22:13AM -0400, Joel Fernandes wrote:
> > On Tue, Aug 06, 2019 at 05:29:15PM -0700, Paul E. McKenney wrote:
> > > On Tue, Aug 06, 2019 at 05:20:41PM -0400, Joel Fernandes (Google) wrote:
On Fri, Aug 09, 2019 at 08:16:19AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 08, 2019 at 07:30:14PM -0400, Joel Fernandes wrote:
[snip]
> > > But I could make it something like:
> > > 1. Letting ->head grow if ->head_free busy
> > > 2. If head_free is busy,
On Thu, Aug 08, 2019 at 08:56:07AM -0400, Joel Fernandes wrote:
> On Thu, Aug 08, 2019 at 06:52:32PM +0900, Byungchul Park wrote:
> > On Wed, Aug 07, 2019 at 10:52:15AM -0700, Paul E. McKenney wrote:
> > > > > On Tue, Aug 06, 2019 at 05:20:40PM -0400, Joel Fernandes (
On Thu, Aug 08, 2019 at 01:51:29PM -0700, Paul E. McKenney wrote:
[snip]
> > Also, I am thinking that whenever we do per-slab optimization, then the
> > kmem_cache_free_bulk() can be optimized further. If all pointers are on the
> > same slab, then we can just do virt_to_cache on the first pointer
ARS affects it.
>
> Link: http://lkml.kernel.org/r/20190806123455.487ac...@gandalf.local.home
>
Acked-by: Joel Fernandes (Google)
thanks!!
- Joel
> Suggested-by: Joel Fernandes
> Signed-off-by: Steven Rostedt (VMware)
> ---
> kernel/trace/trace_stack.c | 98 ++
On Thu, Aug 08, 2019 at 11:11:12AM -0700, Paul E. McKenney wrote:
> On Thu, Aug 08, 2019 at 07:26:10PM +0900, Byungchul Park wrote:
> > On Wed, Aug 07, 2019 at 05:45:04AM -0400, Joel Fernandes wrote:
> > > On Tue, Aug 06, 2019 at 04:56:31PM -0700, Paul E. McKenney wro
On Thu, Aug 08, 2019 at 06:52:32PM +0900, Byungchul Park wrote:
> On Wed, Aug 07, 2019 at 10:52:15AM -0700, Paul E. McKenney wrote:
> > > > On Tue, Aug 06, 2019 at 05:20:40PM -0400, Joel Fernandes (Google) wrote:
> > [ . . . ]
> > > >
On Tue, Aug 06, 2019 at 05:29:15PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 06, 2019 at 05:20:41PM -0400, Joel Fernandes (Google) wrote:
> > This test runs kfree_rcu in a loop to measure performance of the new
> > kfree_rcu, with and without patch.
> >
> > To see
On Tue, Aug 06, 2019 at 04:56:31PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 06, 2019 at 05:20:40PM -0400, Joel Fernandes (Google) wrote:
> > Recently a discussion about performance of system involving a high rate
> > of kfree_rcu() calls surfaced on the list [1] which
On Tue, Aug 06, 2019 at 08:03:13PM -0400, Joel Fernandes wrote:
> On Fri, Aug 02, 2019 at 08:14:49AM -0700, Paul E. McKenney wrote:
> > Use of the rcu_data structure's segmented ->cblist for no-CBs CPUs
> > takes advantage of unrelated grace periods, thus reducing the me
On Fri, Aug 02, 2019 at 08:14:49AM -0700, Paul E. McKenney wrote:
> Use of the rcu_data structure's segmented ->cblist for no-CBs CPUs
> takes advantage of unrelated grace periods, thus reducing the memory
> footprint in the face of floods of call_rcu() invocations. However,
> the ->cblist field
seconds (+13% improvement)
If it is desired to run the test but with the traditional (non-batched)
kfree_rcu, for example to compare results, then you could pass along the
rcuperf.kfree_no_batch=1 boot parameter.
Cc: max.byungchul.p...@gmail.com
Cc: byungchul.p...@lge.com
Signed-off-by: Joel
ail.com
Cc: byungchul.p...@lge.com
Cc: kernel-t...@android.com
Cc: kernel-t...@lge.com
Co-developed-by: Byungchul Park
Signed-off-by: Byungchul Park
Signed-off-by: Joel Fernandes (Google)
---
kernel/rcu/tree.c | 198 --
1 file changed, 193 insert
On Tue, Aug 06, 2019 at 12:34:55PM -0400, Steven Rostedt wrote:
> On Tue, 6 Aug 2019 11:48:11 -0400
> Joel Fernandes wrote:
>
>
> > > diff --git a/arch/arm64/include/asm/ftrace.h
> > > b/arch/arm64/include/asm/ftrace.h
> > > index 5ab5200b2bdc..13a
On Fri, Aug 02, 2019 at 12:11:24PM -0400, Steven Rostedt wrote:
> On Fri, 2 Aug 2019 12:09:20 -0400
> Steven Rostedt wrote:
>
> > On Fri, 2 Aug 2019 11:22:59 -0400
> > Steven Rostedt wrote:
> >
> > > I think you are not explaining the issue correctly. From looking at the
> > > document, I
On Mon, Aug 05, 2019 at 12:25:25PM +0100, Will Deacon wrote:
> [+Akashi, since he may remember more of the gory details here]
>
> On Sat, Aug 03, 2019 at 04:26:42AM -0400, Joel Fernandes wrote:
> > On Fri, Aug 02, 2019 at 11:22:59AM -0400, Steven Rostedt wrote:
> > [snip]
&g
On Tue, Aug 06, 2019 at 12:51:49PM +0200, Michal Hocko wrote:
> On Tue 06-08-19 06:45:54, Joel Fernandes wrote:
> > On Tue, Aug 06, 2019 at 10:43:57AM +0200, Michal Hocko wrote:
> > > On Mon 05-08-19 13:04:50, Joel Fernandes (Google) wrote:
> > > > During idle t
On Mon, Aug 05, 2019 at 04:55:47PM +0900, Minchan Kim wrote:
> Hi Joel,
Hi Minchan,
> On Wed, Jul 31, 2019 at 01:19:37PM -0400, Joel Fernandes wrote:
> > > > -static struct page *page_idle_get_page(unsigned long pfn)
> > > > +static struct page *page_idle
On Sat, Aug 03, 2019 at 12:46:11PM -0700, Paul E. McKenney wrote:
> On Sat, Aug 03, 2019 at 01:41:27PM -0400, Joel Fernandes wrote:
> > On Thu, Aug 01, 2019 at 03:50:20PM -0700, Paul E. McKenney wrote:
> > > Currently, there is one no-CBs rcuo kthread per CPU, and these kthreads
On Thu, Aug 01, 2019 at 03:50:20PM -0700, Paul E. McKenney wrote:
> Currently, there is one no-CBs rcuo kthread per CPU, and these kthreads
> are divided into groups. The first rcuo kthread to come online in a
> given group is that group's leader, and the leader both waits for grace
> periods and
On Sat, Aug 3, 2019 at 4:26 AM Joel Fernandes wrote:
>
> On Fri, Aug 02, 2019 at 11:22:59AM -0400, Steven Rostedt wrote:
> [snip]
> > > There is not PC in ARM64 stack, LR is used to for walk_stackframe in
> > > ARM64. Tere is no the issue in ARM32 because there is
On Fri, Aug 02, 2019 at 11:22:59AM -0400, Steven Rostedt wrote:
[snip]
> > There is not PC in ARM64 stack, LR is used to for walk_stackframe in
> > ARM64. Tere is no the issue in ARM32 because there is PC in ARM32 stack.
> > PC is used to calculate the stack size in trace_stack.c, so the
> >
On Thu, Aug 1, 2019 at 5:39 PM Joel Fernandes (Google)
wrote:
>
> This series fixes the rcu/dev branch with the new ReST conversion patches.
>
And as always, the patch 3/7 made it only to patchwork ;-)
https://lore.kernel.org/patchwork/patch/1109660/
Mauro's auto conversion broken these links, fix them.
Signed-off-by: Joel Fernandes (Google)
---
.../Tree-RCU-Memory-Ordering.rst | 17 ++--
.../RCU/Design/Requirements/Requirements.rst | 90 ---
2 files changed, 47 insertions(+), 60 deletions(-)
diff --git
This restores docs back in ReST format.
---
.../RCU/Design/Requirements/Requirements.rst | 54 +++
1 file changed, 54 insertions(+)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst
b/Documentation/RCU/Design/Requirements/Requirements.rst
index
This reverts docs from commit 355e9972da81e803bbb825b76106ae9b358caf8e.
---
Documentation/RCU/Design/Requirements/Requirements.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html
This series fixes the rcu/dev branch with the new ReST conversion patches.
Only changes are to documentation.
thanks,
- Joel
Joel Fernandes (Google) (6):
Revert docs from "rcu: Restore barrier() to rcu_read_lock() and
rcu_read_unlock()"
Revert docs from "t
These documents are long and have various sections. Provide a good
toc nesting level.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst
index
This restores docs back in ReST format.
---
Documentation/RCU/Design/Requirements/Requirements.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst
b/Documentation/RCU/Design/Requirements/Requirements.rst
index
This reverts docs from commit d6b9cd7dc8e041ee83cb1362fce59a3cdb1f2709.
---
.../RCU/Design/Requirements/Requirements.html | 71 ---
1 file changed, 71 deletions(-)
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html
On Thu, Aug 1, 2019 at 3:58 PM Paul E. McKenney wrote:
>
> On Thu, Aug 01, 2019 at 02:14:02PM -0400, Joel Fernandes (Google) wrote:
> > This series fixes the rcu/dev branch so it can apply the new ReST
> > conversion patches.
> >
> > Patches based on "00ec8f46
On Thu, Aug 1, 2019 at 2:14 PM Joel Fernandes (Google)
wrote:
>
> This series fixes the rcu/dev branch so it can apply the new ReST conversion
> patches.
Weirdly enough, Patch 4/9 did not get received by the archive, but
patchwork did pick it up:
https://lore.kernel.org/patchwork/patch/1109574/
This reverts commit 43ddb98ebe7171ff1c6e11c1616fd03726d8e9bf while
adding the documentation that the original commit added but in ReST
format.
---
.../RCU/Design/Requirements/Requirements.rst | 54 +++
kernel/rcu/tree_plugin.h | 11
2 files changed, 54
This reverts commit 355e9972da81e803bbb825b76106ae9b358caf8e.
---
Documentation/RCU/Design/Requirements/Requirements.html | 2 +-
arch/powerpc/include/asm/kvm_book3s_64.h| 2 +-
include/linux/rculist.h | 6 +++---
include/linux/rcupdate.h
These documents are long and have various sections. Provide a good
toc nesting level.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/index.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/RCU/index.rst b/Documentation/RCU/index.rst
index
This reverts commit 24be1727c524b5874d5dc7828cd392cf86c3341e.
---
include/linux/rculist.h | 32
include/linux/rcupdate.h | 7 +
kernel/rcu/Kconfig.debug | 11 +++
kernel/rcu/update.c | 65 ++--
4 files changed, 88
Mauro's auto conversion broken these links, fix them.
Signed-off-by: Joel Fernandes (Google)
---
.../Tree-RCU-Memory-Ordering.rst | 17 ++--
.../RCU/Design/Requirements/Requirements.rst | 90 ---
2 files changed, 47 insertions(+), 60 deletions(-)
diff --git
This reverts commit 61d814760f1d2dffdc8db636f70bbef07c30acd5.
---
Documentation/RCU/Design/Requirements/Requirements.rst | 2 +-
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
include/linux/rculist.h| 6 +++---
include/linux/rcupdate.h
This reverts commit 50ad3f1f9b13c8a6f2ae79df4cecb2c21da1c7c8.
---
include/linux/rculist.h | 32
include/linux/rcupdate.h | 7 -
kernel/rcu/Kconfig.debug | 11 ---
kernel/rcu/update.c | 65 ++--
4 files changed, 27
oc patches, and then applying them again. But in the
re-application, we convert the documentation
No manual fix ups were done in this process, other than to documentation.
thanks,
- Joel
And in the process I learnt about get_user() and compiler barriers ;-)
Joel Fernandes (Google) (8):
Revert "rcu:
This reverts commit d6b9cd7dc8e041ee83cb1362fce59a3cdb1f2709.
---
.../RCU/Design/Requirements/Requirements.html | 71 ---
kernel/rcu/tree_plugin.h | 11 +++
2 files changed, 11 insertions(+), 71 deletions(-)
diff --git
On Mon, Jul 29, 2019 at 10:15 PM Steven Rostedt wrote:
[snip]
> > If the problem was only with userstacktrace, it will be reasonable to
> > surround only the userstack unwinder. But the situation is similar to
> > the previous "tracing vs CR2" case. As Peter taught me in
> >
#syz invalid
(Could not reproduce this syzbot old bug and it keeps pinging me. Will just let
syzbot open another one if it sees it again. Likely something to do with
overcommit settings misconfigured on the test system).
On Mon, Jan 15, 2018 at 03:58:01PM -0800, syzbot wrote:
> Hello,
>
>
: Alan Stern
Signed-off-by: Joel Fernandes (Google)
---
tools/memory-model/Documentation/explanation.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/memory-model/Documentation/explanation.txt
b/tools/memory-model/Documentation/explanation.txt
index 68caa9
On Mon, Jul 29, 2019 at 01:50:44PM +0800, Boqun Feng wrote:
> On Sun, Jul 28, 2019 at 11:35:44AM -0400, Joel Fernandes wrote:
> [...]
> > > > > > +load of y (rfe link), P2's smp_store_release() ensures that P2's
> > > > > > load
> > > > &
On Sun, Jul 28, 2019 at 11:28:06PM +0800, Boqun Feng wrote:
> On Sun, Jul 28, 2019 at 11:19:59AM -0400, Joel Fernandes wrote:
> > On Sun, Jul 28, 2019 at 10:48:51AM -0400, Alan Stern wrote:
> > > On Sat, 27 Jul 2019, Joel Fernandes (Google) wrote:
> > >
> >
On Sun, Jul 28, 2019 at 10:48:51AM -0400, Alan Stern wrote:
> On Sat, 27 Jul 2019, Joel Fernandes (Google) wrote:
>
> > The lkmm example about ->prop relation should describe an additional rfe
> > link between P1's store to y and P2's load of y, which should be
> &g
->prop ordering on P0 more clear.
Cc: kernel-t...@android.com
Reviewed-by: Boqun Feng
Signed-off-by: Joel Fernandes (Google)
---
.../memory-model/Documentation/explanation.txt | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/tools/memory-model/Docu
0 more clear.
Signed-off-by: Joel Fernandes (Google)
---
tools/memory-model/Documentation/explanation.txt | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/tools/memory-model/Documentation/explanation.txt
b/tools/memory-model/Documentation/explanation.txt
On Fri, Jul 26, 2019 at 3:18 PM Joel Fernandes wrote:
>
> On Fri, Jul 26, 2019 at 11:39:56AM -0700, Alexei Starovoitov wrote:
[snip]
> > > For bpf program:
> > > https://android.googlesource.com/platform/system/bpfprogs/+/908f6cd718fab0de7a944f84628c56f292ef
On Fri, Jul 26, 2019 at 11:39:56AM -0700, Alexei Starovoitov wrote:
[snip]
> > > > 1. timeinstate: By hooking 2 programs onto sched_switch and
> > > > cpu_frequency
> > > > tracepoints, we are able to collect CPU power per-UID (specific app).
> > > > Connor
> > > > O'Brien is working on that.
>
On Fri, Jul 26, 2019 at 02:16:20PM +0300, Konstantin Khlebnikov wrote:
> On 26.07.2019 3:06, Joel Fernandes wrote:
> > On Thu, Jul 25, 2019 at 11:15:53AM +0300, Konstantin Khlebnikov wrote:
> > [snip]
> > > > > > Thanks for bringing up the swapp
On Wed, Jul 24, 2019 at 4:24 PM John Stultz wrote:
>
> On Wed, Jul 24, 2019 at 1:18 PM John Stultz wrote:
> >
> > On Wed, Jul 24, 2019 at 12:36 PM Laura Abbott wrote:
> > >
> > > On 7/17/19 12:31 PM, Alexander Popov wrote:
> > > > Hello!
> > > >
> > > > The syzkaller [1] has a trouble with
e read. This can potentially exhaust page
> reserves which things like networking Rx interrupts need and can make
> this whole feature less reliable.
For the revision, I will pre-allocate the page nodes in advance so it does
not need to do this. Diff on top of this patch is below. Let me
add a warning to catch it in the
future.
[1] https://lore.kernel.org/lkml/20190717172100.261204-1-j...@joelfernandes.org/
Signed-off-by: Joel Fernandes (Google)
---
kernel/signal.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/signal.c b/kernel/signal.c
index 91b789dd6e72
On Wed, Jul 24, 2019 at 01:28:42PM +0900, Minchan Kim wrote:
> On Tue, Jul 23, 2019 at 10:20:49AM -0400, Joel Fernandes wrote:
> > On Tue, Jul 23, 2019 at 03:13:58PM +0900, Minchan Kim wrote:
> > > Hi Joel,
> > >
> > > On Mon, Jul 22, 2019 at 05:32:04PM
On Tue, Jul 23, 2019 at 03:11:10PM -0700, Alexei Starovoitov wrote:
> > > > > I think allowing one tracepoint and disallowing another is pointless
> > > > > from security point of view. Tracing bpf program can do bpf_probe_read
> > > > > of anything.
> > > >
> > > > I think the assumption here is
On Tue, Jul 23, 2019 at 04:59:07PM +0300, Konstantin Khlebnikov wrote:
>
>
> On 23.07.2019 16:46, Joel Fernandes wrote:
> > On Tue, Jul 23, 2019 at 02:54:26PM +0300, Konstantin Khlebnikov wrote:
> > > The page_idle tracking feature currently requires looking up the pag
maps (_rollup).
>
> Piece of comment is stolen from Joel Fernandes
This will not work well for the problem at hand, the heap profiler
(heapprofd) only wants to clear the idle flag for the heap memory area which
is what it is profiling. There is no reason to do it for all mapped pages.
, address
space changes can occur between reading the pagemap and reading the
bitmap. In virtual address indexing, the process's mmap_sem is held for
the duration of the access.
Cc: vdavydov@gmail.com
Cc: Brendan Gregg
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google
[snip]
> > Would it make sense to have call_rcu() check to see if there are many
> > outstanding requests on this CPU and if so process them before returning?
> > That would ensure that frequent callers usually ended up doing their
> > own processing.
Other than what Paul already mentioned about
On Fri, Jul 19, 2019 at 3:57 PM Paul E. McKenney wrote:
>
> On Fri, Jul 19, 2019 at 06:57:58PM +0900, Byungchul Park wrote:
> > On Fri, Jul 19, 2019 at 4:43 PM Paul E. McKenney
> > wrote:
> > >
> > > On Thu, Jul 18, 2019 at 08:52:52PM -0400, Joel Fernandes
701 - 800 of 4053 matches
Mail list logo
