On Wed, Apr 26, 2023 at 8:30 AM Michael Ellerman wrote:
>
> Joel Fernandes writes:
> > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
> ...
> >
> > Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> > canary? Michael, is this an optimi
Hi Zhouyi,
On Wed, Apr 26, 2023 at 09:31:17AM +0800, Zhouyi Zhou wrote:
[..]
> Joel makes the learning process easier for me, indeed!
I know that feeling being a learner myself ;-)
> One question I have tried very hard to understand, but still confused.
> for now, I know
> r13 is fixed, but r1 i
On Tue, Apr 25, 2023 at 9:40 AM Christophe Leroy
wrote:
>
>
>
> Le 25/04/2023 à 13:06, Joel Fernandes a écrit :
> > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
> >>
> >> hi
> >>
> >> On Tue, Apr 25, 2023 at 6:13 PM Peter Zijlstra
On Tue, Apr 25, 2023 at 9:50 AM Zhouyi Zhou wrote:
>
> Hi
>
> On Tue, Apr 25, 2023 at 9:40 PM Christophe Leroy
> wrote:
> >
> >
> >
> > Le 25/04/2023 à 13:06, Joel Fernandes a écrit :
> > > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
> &
On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
>
> hi
>
> On Tue, Apr 25, 2023 at 6:13 PM Peter Zijlstra wrote:
> >
> > On Mon, Apr 24, 2023 at 02:55:11PM -0400, Joel Fernandes wrote:
> > > This is amazing debugging Boqun, like a boss! One comment below:
>
On Tue, Apr 25, 2023 at 6:13 AM Peter Zijlstra wrote:
>
> On Mon, Apr 24, 2023 at 02:55:11PM -0400, Joel Fernandes wrote:
> > This is amazing debugging Boqun, like a boss! One comment below:
> >
> > > > > Or something simple I haven't thought of? :)
> &g
This is amazing debugging Boqun, like a boss! One comment below:
> > > Or something simple I haven't thought of? :)
> >
> > At what points can r13 change? Only when some particular functions are
> > called?
> >
>
> r13 is the local paca:
>
> register struct paca_struct *local_paca asm("r1
On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote:
>
> Dear PowerPC and RCU developers:
> During the RCU torture test on mainline (on the VM of Opensource Lab
> of Oregon State University), SRCU-P failed with __stack_chk_fail:
> [ 264.381952][ T99] [c6c7bab0] [c10c67c0]
> dump_s
Hi Zhouyi,
On Sat, Apr 22, 2023 at 2:47 PM Zhouyi Zhou wrote:
>
> Dear PowerPC and RCU developers:
> During the RCU torture test on mainline (on the VM of Opensource Lab
> of Oregon State University), SRCU-P failed with __stack_chk_fail:
> [ 264.381952][ T99] [c6c7bab0] [c10c67
On Mon, Dec 14, 2020 at 10:36:29AM +0100, Laurent Dufour wrote:
> Le 14/12/2020 à 03:03, Joel Fernandes a écrit :
> > On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
> > [..]
> > > > > Hi Laurent,
> > > > >
> > > > > We
On Tue, Jul 07, 2020 at 01:31:37PM +0800, Chinwen Chang wrote:
[..]
> > > Hi Laurent,
> > >
> > > We merged SPF v11 and some patches from v12 into our platforms. After
> > > several experiments, we observed SPF has obvious improvements on the
> > > launch time of applications, especially for those
On Tue, Mar 24, 2020 at 08:15:39AM +, Will Deacon wrote:
> On Mon, Mar 23, 2020 at 02:23:49PM -0400, Joel Fernandes wrote:
> > On Sun, Mar 22, 2020 at 08:51:15AM +0200, Kalle Valo wrote:
> > > "Joel Fernandes (Google)" writes:
> > >
> > > > Re
On Sun, Mar 22, 2020 at 08:51:15AM +0200, Kalle Valo wrote:
> "Joel Fernandes (Google)" writes:
>
> > Reword and clarify better about the rwsem non-owner release issue.
> >
> > Link: https://lore.kernel.org/linux-pci/20200321212144.ga6...@google.com/
> >
&
Reword and clarify better about the rwsem non-owner release issue.
Link: https://lore.kernel.org/linux-pci/20200321212144.ga6...@google.com/
Signed-off-by: Joel Fernandes (Google)
---
Documentation/locking/locktypes.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
On Sat, Mar 21, 2020 at 10:49:04PM +0100, Thomas Gleixner wrote:
[...]
> >> +rwsems have grown interfaces which allow non owner release for special
> >> +purposes. This usage is problematic on PREEMPT_RT because PREEMPT_RT
> >> +substitutes all locking primitives except semaphores with RT-mutex ba
erfaces which allow non owner release for special
> +purposes. This usage is problematic on PREEMPT_RT because PREEMPT_RT
> +substitutes all locking primitives except semaphores with RT-mutex based
> +implementations to provide priority inheritance for all lock types except
> +the truly spinning ones. Priority inheritance on ownerless locks is
> +obviously impossible.
> +
> +For now the rwsem non-owner release excludes code which utilizes it from
> +being used on PREEMPT_RT enabled kernels.
I could not parse the last sentence here, but I think you meant "For now,
PREEMPT_RT enabled kernels disable code that perform a non-owner release of
an rwsem". Correct me if I'm wrong.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> In same cases this can be
> +mitigated by disabling portions of the code, in other cases the complete
> +functionality has to be disabled until a workable solution has been found.
>
gt; concurrent waiters which for now does not cause a latency problem. Keep it
> simple for now.
>
> The fixup of the warning check in the USB gadget driver is just a straight
> forward conversion of the lockless waiter check from one waitqueue type to
> the other.
>
> Sign
On Fri, Jul 12, 2019 at 08:01:07AM -0700, Paul E. McKenney wrote:
> On Thu, Jul 11, 2019 at 04:45:41PM -0400, Joel Fernandes (Google) wrote:
> > The rcu_dereference_raw_notrace() API name is confusing.
> > It is equivalent to rcu_dereference_raw() except that it also does
>
On Thu, Jul 11, 2019 at 4:45 PM Joel Fernandes (Google)
wrote:
>
> The rcu_dereference_raw_notrace() API name is confusing.
> It is equivalent to rcu_dereference_raw() except that it also does
> sparse pointer checking.
>
> There are only a few users of rcu_dereference_r
check" indicating sparse checking.
Signed-off-by: Joel Fernandes (Google)
---
Previous discussion is here:
https://lore.kernel.org/linuxppc-dev/20190528200014.gv28...@linux.ibm.com/T/
Documentation/RCU/Design/Requirements/Requirements.html | 2 +-
arch/powerpc/include/asm/kvm_book3s_64.h
On Tue, May 28, 2019 at 05:24:47AM -0700, Paul E. McKenney wrote:
> On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
> > On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
> > > On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
>
On Sat, May 25, 2019 at 02:14:07PM -0400, Joel Fernandes wrote:
[snip]
> > That aside, if we are going to change the name of an API that is
> > used 160 places throughout the tree, we would need to have a pretty
> > good justification. Without such a justification, it will
On Sat, May 25, 2019 at 08:50:35AM -0700, Paul E. McKenney wrote:
> On Sat, May 25, 2019 at 10:19:54AM -0400, Joel Fernandes wrote:
> > On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> > > On Sat, 25 May 2019 04:14:44 -0400
> > > Joel Fernandes wrote:
&
On Sat, May 25, 2019 at 07:08:26AM -0400, Steven Rostedt wrote:
> On Sat, 25 May 2019 04:14:44 -0400
> Joel Fernandes wrote:
>
> > > I guess the difference between the _raw_notrace and just _raw variants
> > > is that _notrace ones do a rcu_check_sparse(). Don't
On Fri, May 24, 2019 at 11:24:58PM -0400, Steven Rostedt wrote:
> On Fri, 24 May 2019 19:49:28 -0400
> "Joel Fernandes (Google)" wrote:
>
> > The series removes users of the following APIs, and the APIs themselves,
> > since
> > the regular non - _notrace
The series removes all users of the API and with this patch, the API
itself. Also fix documentation.
Signed-off-by: Joel Fernandes (Google)
---
Documentation/RCU/Design/Requirements/Requirements.html | 6 +++---
include/linux/rcupdate.h| 9 -
2 files
The series removes all users of the API and with this patch, the API
itself.
Signed-off-by: Joel Fernandes (Google)
---
.clang-format | 1 -
include/linux/rculist.h | 20
2 files changed, 21 deletions(-)
diff --git a/.clang-format b/.clang-format
index
hlist_for_each_entry_rcu already does not do any tracing. This series
removes the notrace variant of it, so let us just use the regular API.
In a future patch, we can also remove the
hash_for_each_possible_rcu_notrace API that this patch touches.
Signed-off-by: Joel Fernandes (Google
rcu_dereference_raw_notrace API) with hlist_for_each_entry_rcu which
also does not do any tracing.
Signed-off-by: Joel Fernandes (Google)
---
kernel/trace/ftrace.c | 4 ++--
kernel/trace/ftrace_internal.h | 8
kernel/trace/trace.c | 4 ++--
3 files changed, 8 insertions(+), 8
The series removes users of the following APIs, and the APIs themselves, since
the regular non - _notrace variants don't do any tracing anyway.
* hlist_for_each_entry_rcu_notrace
* rcu_dereference_raw_notrace
Joel Fernandes (Google) (5):
powerpc: Use regular rcu_dereference_raw API
trace
rcu_dereference_raw already does not do any tracing. There is no need to
use the _notrace variant of it and this series removes that API, so let us
use the regular variant here.
Signed-off-by: Joel Fernandes (Google)
---
arch/powerpc/include/asm/kvm_book3s_64.h | 2 +-
1 file changed, 1
Hi Christian,
For next revision, could you also CC sur...@google.com as well? He is also
working on the low memory killer. And also suggest CC to
kernel-t...@android.com. And mentioned some comments below, thanks.
On Thu, May 16, 2019 at 03:59:42PM +0200, Christian Brauner wrote:
[snip]
> diff
erned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
The conflict resolution looks good to me.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
From: "Joel Fernandes (Google)"
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slo
From: "Joel Fernandes (Google)"
Moving page-tables at the PMD-level on x86 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Suggested-by: Kirill A. Shutemov
Acked-by: Kirill A. Shutemov
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/Kconfi
From: "Joel Fernandes (Google)"
This series speeds up mremap(2) syscall by copying page tables at the
PMD level even for non-THP systems. There is concern that the extra
'address' argument that mremap passes to pte_alloc may do something
subtle architecture related in the
"mm: speed up mremap by 500x on large regions" for more
details.
Joel Fernandes (Google) (3):
mm: treewide: remove unused address argument from pte_alloc functions
(v2)
mm: speed up mremap by 20x on large regions (v5)
mm: select HAVE_MOVE_PMD in x86 for faster mremap
arch/Kconfig
On Sun, Nov 04, 2018 at 12:56:48AM -0600, William Kucharski wrote:
>
>
> > On Nov 3, 2018, at 12:32 PM, Joel Fernandes wrote:
> >
> > Looks like more architectures don't define set_pmd_at. I am thinking the
> > easiest way forward is to just do the following,
On Sat, Nov 03, 2018 at 09:24:05AM +, Anton Ivanov wrote:
> On 03/11/2018 09:15, Richard Weinberger wrote:
> > Joel,
> >
> > Am Samstag, 3. November 2018, 05:00:38 CET schrieb Joel Fernandes:
> > > Hi,
> > > Here is the latest "fast mremap" ser
On Sat, Nov 03, 2018 at 09:24:05AM +, Anton Ivanov wrote:
> On 03/11/2018 09:15, Richard Weinberger wrote:
> > Joel,
> >
> > Am Samstag, 3. November 2018, 05:00:38 CET schrieb Joel Fernandes:
> > > Hi,
> > > Here is the latest "fast mremap" ser
From: "Joel Fernandes (Google)"
Moving page-tables at the PMD-level on x86 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Suggested-by: Kirill A. Shutemov
Acked-by: Kirill A. Shutemov
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/Kconfi
From: "Joel Fernandes (Google)"
Android needs to mremap large regions of memory during memory management
related operations. The mremap system call can be really slow if THP is
not enabled. The bottleneck is move_page_tables, which is copying each
pte at a time, and can be really slo
From: "Joel Fernandes (Google)"
This series speeds up mremap(2) syscall by copying page tables at the
PMD level even for non-THP systems. There is concern that the extra
'address' argument that mremap passes to pte_alloc may do something
subtle architecture related in the
blaze.
not included - (4) mm: select HAVE_MOVE_PMD in arm64 for faster mremap
This patch is dropped since last posting pending further performance
testing on arm64 with new TLB gather updates. See notes in patch
titled "mm: speed up mremap by 500x on large regions" for more
Hi Balbir,
On Sat, Oct 27, 2018 at 09:21:02PM +1100, Balbir Singh wrote:
> On Wed, Oct 24, 2018 at 07:13:50PM -0700, Joel Fernandes wrote:
> > On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
> > [...]
> > > > > + pmd_t pmd;
> > >
On Thu, Oct 25, 2018 at 01:19:00PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 24, 2018 at 07:09:07PM -0700, Joel Fernandes wrote:
> > On Wed, Oct 24, 2018 at 03:57:24PM +0300, Kirill A. Shutemov wrote:
> > > On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
>
On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
[...]
> > > + pmd_t pmd;
> > > +
> > > + new_ptl = pmd_lockptr(mm, new_pmd);
>
>
> Looks like this is largely inspired by move_huge_pmd(), I guess a lot of
> the code applies, why not just reuse as much as possible? The
On Wed, Oct 24, 2018 at 03:57:24PM +0300, Kirill A. Shutemov wrote:
> On Wed, Oct 24, 2018 at 10:57:33PM +1100, Balbir Singh wrote:
> > On Wed, Oct 24, 2018 at 01:12:56PM +0300, Kirill A. Shutemov wrote:
> > > On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) w
On Wed, Oct 24, 2018 at 10:37:16AM +0200, Peter Zijlstra wrote:
> On Fri, Oct 12, 2018 at 06:31:57PM -0700, Joel Fernandes (Google) wrote:
> > This series speeds up mremap(2) syscall by copying page tables at the
> > PMD level even for non-THP systems. There is concern that the ext
On Tue, Oct 16, 2018 at 01:29:52PM +0200, Vlastimil Babka wrote:
> On 10/16/18 12:33 AM, Joel Fernandes wrote:
> > On Mon, Oct 15, 2018 at 02:42:09AM -0700, Christoph Hellwig wrote:
> >> On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> >>>
On Mon, Oct 15, 2018 at 10:18:14AM +0200, Martin Schwidefsky wrote:
> On Mon, 15 Oct 2018 09:10:53 +0200
> Christian Borntraeger wrote:
>
> > On 10/12/2018 03:37 AM, Joel Fernandes (Google) wrote:
> > > Android needs to mremap large regions of memory during memory
On Mon, Oct 15, 2018 at 02:42:09AM -0700, Christoph Hellwig wrote:
> On Fri, Oct 12, 2018 at 06:31:58PM -0700, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations.
>
> Just curious: why?
On Fri, Oct 12, 2018 at 07:25:08PM -0700, Daniel Colascione wrote:
[...]
> > But anyway, I think this runtime detection thing is not needed. THP is
> > actually expected to be as fast as this anyway, so if that's available then
> > we should already be as fast.
>
> Ah, I think the commit message
Moving page-tables at the PMD-level on x86 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Signed-off-by: Joel Fernandes (Google)
---
arch/x86/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1a0be022f91d
Moving page-tables at the PMD-level on arm64 is known to be safe. Enable
this option so that we can do fast mremap when possible.
Signed-off-by: Joel Fernandes (Google)
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index
4 and arm64.
Cc: minc...@kernel.org
Cc: pan...@google.com
Cc: hu...@google.com
Cc: lokeshgi...@google.com
Cc: dan...@google.com
Cc: mho...@kernel.org
Cc: kir...@shutemov.name
Cc: a...@linux-foundation.org
Cc: kernel-t...@android.com
Signed-off-by: Joel Fernandes (Google)
---
arch/Kconfig | 5 +++
e
+ #define fn(a, b) e
|
- #define fn(a, b) e
+ #define fn(a) e
)
Suggested-by: Kirill A. Shutemov
Cc: Kirill A. Shutemov
Cc: Michal Hocko
Cc: Julia Lawall
Signed-off-by: Joel Fernandes (Google)
---
arch/alpha/include/asm/pgalloc.h | 6 +++---
arch/arc/include/asm/pgalloc.h
v1 (Anton Ivanov)
update changelog with manual fixups for m68k and microblaze.
Joel Fernandes (Google) (4):
treewide: remove unused address argument from pte_alloc functions (v2)
mm: speed up mremap by 500x on large regions (v2)
arm64: select HAVE_MOVE_PMD for faster mremap (v
On Fri, Oct 12, 2018 at 06:54:33PM -0700, Daniel Colascione wrote:
> I wonder whether it makes sense to expose to userspace somehow whether
> mremap is "fast" for a particular architecture. If a feature relies on
> fast mremap, it might be better for some userland component to disable
> that featur
On Fri, Oct 12, 2018 at 06:39:45PM -0700, Daniel Colascione wrote:
> Not 32-bit ARM?
Well, I didn't want to enable every possible architecture we could in a
single go. Certainly arm32 can be a follow on enablement as can be other
architectures. The point of this series is to upstream this feature
On Fri, Oct 12, 2018 at 11:18:36AM -0700, David Miller wrote:
> From: Joel Fernandes
[...]
> > Also, do we not flush the caches from any path when we munmap
> > address space? We do call do_munmap on the old mapping from mremap
> > after moving to the new one.
>
> S
On Fri, Oct 12, 2018 at 08:51:45PM +0200, SF Markus Elfring wrote:
> > The changes were obtained by applying the following Coccinelle script.
>
> A bit of clarification happened for its implementation details.
> https://systeme.lip6.fr/pipermail/cocci/2018-October/005374.html
>
> I have taken als
On Fri, Oct 12, 2018 at 05:58:40PM +0100, Anton Ivanov wrote:
[...]
> > > > > > If I read the code right, MIPS completely ignores the address
> > > > > > argument so
> > > > > > set_pmd_at there may not have the effect which this patch is trying
> > > > > > to
> > > > > > achieve.
> > > > > Ignori
On Fri, Oct 12, 2018 at 04:19:46PM +0300, Kirill A. Shutemov wrote:
> On Fri, Oct 12, 2018 at 05:50:46AM -0700, Joel Fernandes wrote:
> > On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> > > On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernan
On Fri, Oct 12, 2018 at 05:42:24PM +0100, Anton Ivanov wrote:
>
> On 10/12/18 3:48 PM, Anton Ivanov wrote:
> > On 12/10/2018 15:37, Kirill A. Shutemov wrote:
> > > On Fri, Oct 12, 2018 at 03:09:49PM +0100, Anton Ivanov wrote:
> > > > On 10/12/18 2:37
On Fri, Oct 12, 2018 at 06:38:57PM +0200, Julia Lawall wrote:
> > I wrote something like this as below but it failed to compile, Julia any
> > suggestions on how to express this?
> >
> > @pte_alloc_func_proto depends on patch exists@
> > type T1, T2, T3, T4;
> > identifier fn =~
> > "^(__pte_alloc|
On Fri, Oct 12, 2018 at 02:09:06PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:55PM -0700, Joel Fernandes (Google) wrote:
> > diff --git a/arch/m68k/include/asm/mcf_pgalloc.h
> > b/arch/m68k/include/asm/mcf_pgalloc.h
> > index 12fe700632f4..4399d712f6db
On Fri, Oct 12, 2018 at 02:56:19PM +0100, Anton Ivanov wrote:
>
> On 10/12/18 2:37 AM, Joel Fernandes (Google) wrote:
> > This series speeds up mremap(2) syscall by copying page tables at the
> > PMD level even for non-THP systems. There is concern that the extra
> >
On Fri, Oct 12, 2018 at 02:30:56PM +0300, Kirill A. Shutemov wrote:
> On Thu, Oct 11, 2018 at 06:37:56PM -0700, Joel Fernandes (Google) wrote:
> > Android needs to mremap large regions of memory during memory management
> > related operations. The mremap system call can be really
4 and arm64.
Cc: minc...@kernel.org
Cc: pan...@google.com
Cc: hu...@google.com
Cc: lokeshgi...@google.com
Cc: dan...@google.com
Cc: mho...@kernel.org
Cc: kir...@shutemov.name
Cc: a...@linux-foundation.org
Signed-off-by: Joel Fernandes (Google)
---
mm/mremap.c
e
|
- #define fn(a, b)@p e
+ #define fn(a) e
)
Suggested-by: Kirill A. Shutemov
Cc: Michal Hocko
Cc: Julia Lawall
Cc: elfr...@users.sourceforge.net
Signed-off-by: Joel Fernandes (Google)
---
arch/alpha/include/asm/pgalloc.h | 6 +++---
arch/arc/include/asm/pgalloc.h
71 matches
Mail list logo
