On Sat, Jul 30, 2022 at 09:52:34PM +0200, Rafael J. Wysocki wrote:
> On Sat, Jul 30, 2022 at 11:48 AM Michel Lespinasse
> wrote:
> > I'm not sure if that was the patch you meant to send though, as it
> > seems it's only adding a tracepoint so shouldn't make any difference
>
On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> wrote:
> >
> > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse
On Fri, Jul 29, 2022 at 08:26:22AM -0700, Paul E. McKenney wrote:> Would you be
willing to try another shot in the dark, but untested
> this time? I freely admit that this is getting strange.
>
> Thanx, Paul
Yes, adding this second change
On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 o
On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> Xeons") wrecked intel_idle in two ways:
>
> - must not have tracing in idle functions
> - must return with IRQs disabled
>
> Additionally, it added a branch for
single threaded workload - kernbench would be
fine - without the special-case optimization in patch 22 where
handle_speculative_fault() immediately aborts in the single-threaded case.
Reviewed-by: Michel Lespinasse
This is for the series as a whole; I expect to do another review pass on
individual commit
On Thu, Feb 21, 2013 at 3:05 PM, a...@linux-foundation.org wrote:
From: Michel Lespinasse wal...@google.com
Subject: mm: remove free_area_cache use in powerpc architecture
As all other architectures have been converted to use vm_unmapped_area(),
we are about to retire the free_area_cache
On Mon, Mar 18, 2013 at 4:12 AM, Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
how about ?
static bool slice_scan_available(unsigned long addr,
struct slice_mask available,
int end,
take both the lglock write side and the fallback_rwlock, thus
making sure to exclude both local and global readers.
Thanks to Srivatsa S. Bhat for proposing a lock with these requirements
and Lai Jiangshan for proposing this algorithm as an lglock extension.
Signed-off-by: Michel Lespinasse wal
On Tue, Mar 5, 2013 at 7:54 AM, Lai Jiangshan la...@cn.fujitsu.com wrote:
On 03/03/13 01:06, Oleg Nesterov wrote:
On 03/02, Michel Lespinasse wrote:
My version would be slower if it needs to take the
slow path in a reentrant way, but I'm not sure it matters either :)
I'd say, this doesn't
On Sun, Mar 3, 2013 at 9:40 AM, Oleg Nesterov o...@redhat.com wrote:
However, I still think that FALLBACK_BASE only adds the unnecessary
complications. But even if I am right this is subjective of course, please
feel free to ignore.
Would it help if I sent out that version (without
On Sat, Mar 2, 2013 at 2:28 AM, Oleg Nesterov o...@redhat.com wrote:
Lai, I didn't read this discussion except the code posted by Michel.
I'll try to read this patch carefully later, but I'd like to ask
a couple of questions.
This version looks more complex than Michel's, why? Just curious, I
On Thu, Feb 28, 2013 at 3:25 AM, Oleg Nesterov o...@redhat.com wrote:
On 02/27, Michel Lespinasse wrote:
+void lg_rwlock_local_read_lock(struct lgrwlock *lgrw)
+{
+ preempt_disable();
+
+ if (__this_cpu_read(*lgrw-local_refcnt) ||
+ arch_spin_trylock(this_cpu_ptr(lgrw
Hi Srivatsa,
I think there is some elegance in Lai's proposal of using a local
trylock for the reader uncontended case and global rwlock to deal with
the contended case without deadlocks. He apparently didn't realize
initially that nested read locks are common, and he seems to have
confused you
On Tue, Feb 19, 2013 at 2:50 AM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
But, the whole intention behind removing the parts depending on the
recursive property of rwlocks would be to make it easier to make rwlocks
fair (going forward) right? Then, that won't work for CPU
Hi Srivasta,
I admit not having followed in detail the threads about the previous
iteration, so some of my comments may have been discussed already
before - apologies if that is the case.
On Mon, Feb 18, 2013 at 8:38 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Reader-writer
On Mon, Feb 18, 2013 at 8:39 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
@@ -200,6 +217,16 @@ void percpu_write_lock_irqsave(struct percpu_rwlock
*pcpu_rwlock,
smp_mb(); /* Complete the wait-for-readers, before taking the lock */
On Mon, Feb 18, 2013 at 8:39 PM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
Some important design requirements and considerations:
-
1. Scalable synchronization at the reader-side, especially in the fast-path
Any
On Tue, Feb 19, 2013 at 12:43 AM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 02/18/2013 09:53 PM, Michel Lespinasse wrote:
I am wondering though, if you could take care of recursive uses in
get/put_online_cpus_atomic() instead of doing it as a property of your
rwlock
On Tue, Feb 19, 2013 at 1:56 AM, Srivatsa S. Bhat
srivatsa.b...@linux.vnet.ibm.com wrote:
On 02/18/2013 09:51 PM, Srivatsa S. Bhat wrote:
On 02/18/2013 09:15 PM, Michel Lespinasse wrote:
I don't see anything preventing a race with the corresponding code in
percpu_write_unlock() that sets
testing on x86 and powerpc; however the first 5 (simpler)
patches for parisc, alpha, frv and ia64 architectures are untested.
Michel Lespinasse (8):
mm: use vm_unmapped_area() on parisc architecture
mm: use vm_unmapped_area() on alpha architecture
mm: use vm_unmapped_area() on frv
Update the parisc arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/parisc/kernel/sys_parisc.c | 46
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/alpha/kernel/osf_sys.c | 20 +---
1 files changed
Update the frv arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/frv/mm/elf-fdpic.c | 49
Update the ia64 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/ia64/kernel/sys_ia64.c | 37
Update the ia64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/ia64/mm/hugetlbpage.c | 20 +---
1 files
the
vm_unmapped_area() infrastructure and regain the performance.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/powerpc/include/asm/page_64.h |3 +-
arch/powerpc/mm/hugetlbpage.c|2 +-
arch/powerpc/mm/slice.c
Update the powerpc slice_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/powerpc/mm/slice.c | 123 ++-
1 files changed, 78
Since all architectures have been converted to use vm_unmapped_area(),
there is no remaining use for the free_area_cache.
Signed-off-by: Michel Lespinasse wal...@google.com
Acked-by: Rik van Riel r...@redhat.com
---
arch/arm/mm/mmap.c |2 --
arch/arm64/mm/mmap.c
On Tue, Jan 22, 2013 at 11:32 AM, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2013-01-22 at 13:03 +0530, Srivatsa S. Bhat wrote:
A straight-forward (and obvious) algorithm to implement Per-CPU Reader-Writer
locks can also lead to too many deadlock possibilities which can make it very
of the
copies :-)
All right, does the following look more palatable then ?
(didn't re-test it, though)
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/powerpc/mm/slice.c | 123 ++-
1 files changed, 78 insertions(+), 45 deletions(-)
diff --git
Update the parisc arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/parisc/kernel/sys_parisc.c | 46 ++
1 files changed, 17 insertions
.
Michel Lespinasse (8):
mm: use vm_unmapped_area() on parisc architecture
mm: use vm_unmapped_area() on alpha architecture
mm: use vm_unmapped_area() on frv architecture
mm: use vm_unmapped_area() on ia64 architecture
mm: use vm_unmapped_area() in hugetlbfs on ia64 architecture
mm: remove
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/alpha/kernel/osf_sys.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions
Update the frv arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/frv/mm/elf-fdpic.c | 49 --
1 files changed, 17 insertions
Update the ia64 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/ia64/kernel/sys_ia64.c | 37 -
1 files changed, 12 insertions(+), 25
Update the ia64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/ia64/mm/hugetlbpage.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions
the
vm_unmapped_area() infrastructure and regain the performance.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/powerpc/include/asm/page_64.h |3 +-
arch/powerpc/mm/hugetlbpage.c|2 +-
arch/powerpc/mm/slice.c | 108
Update the powerpc slice_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/powerpc/mm/slice.c | 128 +-
1 files changed, 81
Since all architectures have been converted to use vm_unmapped_area(),
there is no remaining use for the free_area_cache.
Signed-off-by: Michel Lespinasse wal...@google.com
---
arch/arm/mm/mmap.c |2 --
arch/arm64/mm/mmap.c |2 --
arch/mips/mm/mmap.c
Whoops, I was supposed to find a more appropriate subject line before
sending this :]
On Tue, Jan 8, 2013 at 5:28 PM, Michel Lespinasse wal...@google.com wrote:
These patches, which apply on top of v3.8-rc kernels, are to complete the
VMA gap finding code I introduced (following Rik's initial
On Tue, Jan 8, 2013 at 6:15 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2013-01-08 at 17:28 -0800, Michel Lespinasse wrote:
Update the powerpc slice_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off
On Mon, Apr 4, 2011 at 11:24 PM, Michael Ellerman
mich...@ellerman.id.au wrote:
In access_process_vm() we need to check that we have found the right
vma, not the following vma, before we try to access it. Otherwise
we might call the vma's access routine with an address which does
not fall
on mm's more flexible and convenient. In particular, it
allows some code paths to avoid the need to hold task_lock.
Reviewed-by: Michel Lespinasse wal...@google.com
May I suggest ia32_compat instead of just compat for the flag name ?
--
Michel Walken Lespinasse
A program is never fully
44 matches
Mail list logo
