As a page might belong to highmem.
Strictly nested kmap_atomic() order is followed according to doc
Documentation/vm/highmem.txt
CC: Dan Williams
CC: Shaohua Li
Signed-off-by: Yuanhan Liu
---
crypto/async_tx/async_pq.c | 18 +-
crypto/async_tx/async_raid6_recov.c
On Thu, May 14, 2015 at 03:45:11PM +1000, NeilBrown wrote:
> On Wed, 29 Apr 2015 10:48:55 +0800 Yuanhan Liu
> wrote:
>
> > diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> > index 64d5bea..697d77a 100644
> > --- a/drivers/md/raid5.c
> > +++ b/driver
On Fri, May 08, 2015 at 03:28:00PM +1000, NeilBrown wrote:
> On Wed, 6 May 2015 17:45:49 +0800 Yuanhan Liu
> wrote:
>
> > Move the code that put one idle sh(hot in cache, but happens to be
> > zero referenced) back to active stage to __find_stripe(). Because
> > t
f->active_stripes, not being set properly.
So, we should execute the second if block whenever we entered the first
if block no matter sh->count stays with 0 or not.
Signed-off-by: Yuanhan Liu
---
Neil, I'm a bit concerned that I missed something in this patch. Please
kindly correct m
whole story now.
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 50 ++
1 file changed, 18 insertions(+), 32 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 77dfd72..e7fa818 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/
On Mon, May 04, 2015 at 05:24:24PM +1000, NeilBrown wrote:
> On Mon, 4 May 2015 13:50:24 +0800 Yuanhan Liu
> wrote:
>
> > This is to fix a kernel NULL dereference oops introduced by commit
> > 59fc630b("RAID5: batch adjacent full stripe write"), which introduc
] add_stripe_bio+0x48d/0x544
[ 32.388044] RSP
[ 32.388044] CR2:
[ 32.388044] ---[ end trace 2b255d3f55be9eb3 ]---
Cc: Shaohua Li
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5
FYI, we noticed the below changes on
https://github.com/jiangliu/linux.git test/irq_common_data_v2
commit d5b2eacdbc280da7c6dfbe0f52bb293ef227d349 ("genirq: Introduce struct
irq_common_data to host shared irq data")
+-++---
On Thu, Apr 30, 2015 at 05:16:50PM +1000, NeilBrown wrote:
> On Thu, 30 Apr 2015 15:01:17 +0800 Yuanhan Liu
> wrote:
>
> > Signed-off-by: Yuanhan Liu
> > ---
> > drivers/md/raid5.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> >
On Thu, Apr 30, 2015 at 05:14:26PM +1000, NeilBrown wrote:
> On Thu, 30 Apr 2015 15:01:16 +0800 Yuanhan Liu
> wrote:
>
> > bion -> bios
> >
> > Signed-off-by: Yuanhan Liu
> > ---
> > drivers/md/raid5.c | 2 +-
> > 1 file changed, 1 insertion(+)
bion -> bios
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 697d77a..2651bda 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2919,7 +291
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 2651bda..bae3e2c 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -5789,8 +5789,7 @@ static void raid5d(struct
On Fri, Apr 24, 2015 at 12:15:59PM +1000, NeilBrown wrote:
> On Thu, 23 Apr 2015 14:55:59 +0800 Huang Ying wrote:
>
> > FYI, we noticed the below changes on
> >
> > git://neil.brown.name/md for-next
> > commit 878ee6792799e2f88bdcac329845efadb205252f ("RAID5: batch adjacent
> > full stripe writ
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/mlin/linux.git block-generic-req
commit 5a19fe29ba7d052c0d8fa8a2bf461abc1e4d89bb ("block: make
generic_make_request handle arbitrarily sized bios")
testbox/testcase/testparams: vm-kbuild-1G/boot/1
v4.1-r
(active_stripes == 0)
Commit log refactor suggestion from Neil.
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 15 +--
drivers/md/raid5.h | 1 +
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 77dfd72..64d5bea 100644
o 97%. And as expected,
the performance increased a lot, up to 260%, for fast device(ram disk).
v2: use bits instead of array to note down wait queue need to wake up.
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 27 +++
drivers/md/raid5.h | 2 +-
2 files changed
e the same arguments - peterz
Signed-off-by: Yuanhan Liu
---
include/linux/wait.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index 2db8334..db78c72 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -358,6 +35
On Tue, Apr 28, 2015 at 04:13:15PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 27, 2015 at 12:51:01PM +0800, Yuanhan Liu wrote:
> > It's just a variant of wait_event_cmd, with exclusive flag being set.
> >
> > For cases like RAID5, which puts many processes to sleep u
o 97%. And as expected,
the performance increased a lot, up to 260%, for fast device(ram disk).
v2: use bits instead of array to note down wait queue need to wake up.
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 27 +++
drivers/md/raid5.h | 2 +-
2 files changed
That ends up introducing heavy lock contentions, and
hurts performance badly.
Here introduce wait_event_cmd_exclusive to relieve the lock contention
naturally by letting wake_up() just wake up one process.
Cc: Ingo Molnar
Cc: Peter Zijlstra
Signed-off-by: Yuanhan Liu
---
include/linux/w
(active_stripes == 0)
Commit log refactor suggestion from Neil.
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 15 +--
drivers/md/raid5.h | 1 +
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 77dfd72..64d5bea 100644
On Mon, Apr 27, 2015 at 10:24:05AM +1000, NeilBrown wrote:
> On Fri, 24 Apr 2015 21:39:04 +0800 Yuanhan Liu
> wrote:
>
> > I noticed heavy spin lock contention at get_active_stripe() with fsmark
> > multiple thread write workloads.
> >
> > Here is how this h
On Mon, Apr 27, 2015 at 10:10:24AM +1000, NeilBrown wrote:
> On Fri, 24 Apr 2015 21:39:03 +0800 Yuanhan Liu
> wrote:
>
> > If I read code correctly, current wait_for_stripe actually has 2 usage:
> >
> > - wait for there is enough free stripe cache, triggered when
>
it wait_for_stripe, and here I introduce
wait_for_quiesce for the second usage. The name may not well taken, or
even taken wrongly. Feel free to correct me then.
This is also a prepare patch for next patch: make wait_for_stripe
exclusive.
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c | 13 ++
raid on those ramdisk
As you can see, though there are no much performance gain for hard disk
workload, the system time is dropped heavily, up to 97%. And as expected,
the performance increased a lot, up to 260%, for fast device(ram disk).
Signed-off-by: Yuanhan Liu
---
drivers/md/raid5.c
FYI, we found performance increasement, which is expected as commit patch says,
on `fsmark.files_per_sec' by c9dc4c6578502c2085705347375b82089aad18d0:
> commit c9dc4c6578502c2085705347375b82089aad18d0
> Author: Chris Mason
> AuthorDate: Sat Apr 4 17:14:42 2015 -0700
> Commit:
FYI, we found changes on `fsmark.files_per_sec' by
78373b7319abdf15050af5b1632c4c8b8b398f33:
> commit 78373b7319abdf15050af5b1632c4c8b8b398f33
> Author: Jaegeuk Kim
> AuthorDate: Fri Mar 13 21:44:36 2015 -0700
> Commit: Jaegeuk Kim
> CommitDate: Fri Apr 10 15:08:45 2
On Wed, Mar 25, 2015 at 02:03:59PM +1100, NeilBrown wrote:
> On Wed, 18 Mar 2015 13:00:30 +0800 Yuanahn Liu
> wrote:
>
> > Hi,
> >
> > FYI, we noticed performance changes on `fsmark.files_per_sec' by
> > 4400755e356f9a2b0b7ceaa02f57b1c7546c3765:
> >
> > > commit 4400755e356f9a2b0b7ceaa02f5
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 8eb23b9f35aae413140d3fda766a98092c21e9b0 ("sched: Debug nested sleeps")
+-+++
|
FYI, we noticed the below changes on
git://people.freedesktop.org/~airlied/linux.git radeon-mst-hacks
commit f5ef139cbe5dbd755dab3706022d7147800099a8 ("drm/fb: add support for tiled
monitor configurations.")
testbox/testcase/testparams: vm-kbuild-1G/xfstests/4HDD-btrfs-generic-113
9cf13203b1fd
FYI, we noticed the below changes on
commit 4ed2d765dfaccff5ebdac68e2064b59125033a3b ("net-timestamp: TCP
timestamping")
testbox/testcase/testparams: vm-vp-2G/ltp/syscalls
e7fd2885385157d4 4ed2d765dfaccff5ebdac68e20
--
fail:runs %reproduct
FYI, we noticed the below changes on
commit 2a16fc93d2c9568e16d45db77c7b5f15e1921cf1 ("nohz: Avoid tick's double
reprogramming in highres mode")
testbox/testcase/testparams: snb-drag/piglit/performance-igt-001
b5e995e671d8e4d7 2a16fc93d2c9568e16d45db77c
---
Hi,
We noticed the below changes on(NOTE: I'm not sure the bisect is correct
or not, here I report it out JFYI).
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 5fcb864ef90df093d964171539c87ffa0ab49f0f ("x86, irq, ACPI: Implement
interfaces to support ACPI based
FYI, we noticed the below changes on
https://github.com/jiangliu/linux.git irqdomain/p2v7
commit 515b463a5a4c2bac0593c6d88a475a32d65f4bcc ("x86, PCI, MSI: Use hierarchy
irqdomain to manage MSI interrupts")
+--+++
|
FYI, we noticed the below changes on(TBH, I don't know the bisect is
correct or not; sorry for the noise if not)
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git lsm/stacking
commit 58c4f9e3be81a85839ea229b1dd36bf55232d440 ("LSM: Refactor existing LSM
stacking")
+---
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git x86/pmd-nx
commit 3622dcc2b4f4eaf23bae2511a30fc449d0e5f0d9 ("x86, mm: set NX across entire
PMD at boot")
+--+++
|
On Wed, Nov 12, 2014 at 03:44:34PM +0100, Vincent Guittot wrote:
> On 10 November 2014 06:54, wrote:
> > FYI, we noticed the below changes on
> >
> > https://git.linaro.org/people/mturquette/linux.git eas-next
> > commit 9597d64116d0d441dea32e7f5f05fa135d16f44b ("sched: replace
> > capacity_fact
On Fri, Nov 07, 2014 at 10:35:44AM +0100, Ard Biesheuvel wrote:
> On 7 November 2014 10:26, Yuanhan Liu wrote:
> > On Fri, Nov 07, 2014 at 10:03:55AM +0100, Ard Biesheuvel wrote:
> >> On 7 November 2014 09:46, Yuanhan Liu wrote:
> >> > On Fri, Nov 07, 2014 at 09
On Fri, Nov 07, 2014 at 09:16:02AM +, Matt Fleming wrote:
> On Fri, 2014-11-07 at 08:17 +0100, Ard Biesheuvel wrote:
> > On 7 November 2014 06:47, LKP wrote:
> > > FYI, we noticed the below changes on
> > >
> > > https://git.linaro.org/people/ard.biesheuvel/linux-arm efi-for-3.19
> > > commit
On Fri, Nov 07, 2014 at 10:03:55AM +0100, Ard Biesheuvel wrote:
> On 7 November 2014 09:46, Yuanhan Liu wrote:
> > On Fri, Nov 07, 2014 at 09:23:56AM +0100, Ard Biesheuvel wrote:
> >> On 7 November 2014 09:13, Yuanhan Liu wrote:
> >> > On Fri, Nov 07, 2014 at 08
On Fri, Nov 07, 2014 at 09:23:56AM +0100, Ard Biesheuvel wrote:
> On 7 November 2014 09:13, Yuanhan Liu wrote:
> > On Fri, Nov 07, 2014 at 08:44:40AM +0100, Ard Biesheuvel wrote:
> >> On 7 November 2014 08:37, Yuanhan Liu wrote:
> >> > On Fri, Nov 07, 2014 at 08
On Fri, Nov 07, 2014 at 08:44:40AM +0100, Ard Biesheuvel wrote:
> On 7 November 2014 08:37, Yuanhan Liu wrote:
> > On Fri, Nov 07, 2014 at 08:17:36AM +0100, Ard Biesheuvel wrote:
> >> On 7 November 2014 06:47, LKP wrote:
> >> > FYI, we noticed the below
On Fri, Nov 07, 2014 at 08:17:36AM +0100, Ard Biesheuvel wrote:
> On 7 November 2014 06:47, LKP wrote:
> > FYI, we noticed the below changes on
> >
> > https://git.linaro.org/people/ard.biesheuvel/linux-arm efi-for-3.19
> > commit aacdce6e880894acb57d71dcb2e3fc61b4ed4e96 ("dmi: add support for
>
On Thu, May 22, 2014 at 05:30:51PM +0100, Mel Gorman wrote:
> On Fri, May 23, 2014 at 12:14:16AM +0800, Yuanhan Liu wrote:
> > On Thu, May 22, 2014 at 10:09:36AM +0100, Mel Gorman wrote:
> > > This series is aimed at regressions noticed during reclaim activity. The
> >
see if
> there was a reason they were dropped or if they just got lost. Dave? Time?
> The last patch adjusts proportional reclaim. Yuanhan Liu, can you retest
> the vm scalability test cases on a larger machine? Hugh, does this work
> for you on the memcg test cases?
Sure, and here is t
On Sat, Mar 15, 2014 at 08:56:10PM -0700, Hugh Dickins wrote:
> On Fri, 14 Mar 2014, Mel Gorman wrote:
> > On Thu, Mar 13, 2014 at 05:44:57AM -0700, Hugh Dickins wrote:
> > > On Wed, 12 Mar 2014, Mel Gorman wrote:
> > > > On Tue, Feb 18, 2014 at 04:01:22PM +080
On Wed, Mar 12, 2014 at 04:54:47PM +, Mel Gorman wrote:
> On Tue, Feb 18, 2014 at 04:01:22PM +0800, Yuanhan Liu wrote:
> > Hi,
> >
> > Commit e82e0561("mm: vmscan: obey proportional scanning requirements for
> > kswapd") caused a big performance regres
ping...
On Tue, Feb 18, 2014 at 04:01:22PM +0800, Yuanhan Liu wrote:
> Hi,
>
> Commit e82e0561("mm: vmscan: obey proportional scanning requirements for
> kswapd") caused a big performance regression(73%) for vm-scalability/
> lru-file-readonce testcase on a system with
Hi,
Commit e82e0561("mm: vmscan: obey proportional scanning requirements for
kswapd") caused a big performance regression(73%) for vm-scalability/
lru-file-readonce testcase on a system with 256G memory without swap.
That testcase simply looks like this:
truncate -s 1T /tmp/vm-scalability.im
On Wed, Dec 18, 2013 at 11:29:30AM +0100, Matias Bjørling wrote:
> On 12/18/2013 09:50 AM, Yuanhan Liu wrote:
> >Hi,
> >
> >FYI, we noticed some changes caused by 0d11e6ac("blk-mq: fix use-after-free
> >of request"):
> >
>
> The blk-mq accounting
Hi,
FYI, we noticed some changes caused by 0d11e6ac("blk-mq: fix use-after-free of
request"):
- 959a35f13eb785f982d7 is parent of 0d11e6aca396e679c07b
- kbuildx and vpx are KVM testbox
959a35f13eb785f982d7 0d11e6aca396e679c07b
On Thu, Dec 05, 2013 at 05:50:19PM -0500, Tejun Heo wrote:
> On Thu, Dec 05, 2013 at 11:10:51AM +0800, Yuanhan Liu wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit 4b93dc9b1c684d0587fe44d36bbfdf45bd3bea9d
> >
On Tue, Dec 03, 2013 at 05:05:56PM +0800, Alex Shi wrote:
> Task migration happens when target just a bit less then source cpu load.
> To reduce such situation happens, aggravate the target cpu load with
> sd->imbalance_pct/100.
>
> This patch removes the hackbench thread regression on Daniel's
>
On Fri, Nov 29, 2013 at 04:33:00PM +0100, Rafael J. Wysocki wrote:
> On Friday, November 29, 2013 01:25:52 PM Yuanhan Liu wrote:
> > Greetings,
> >
> > We got the follow kernel panic dmesg(full dmesg is attached):
>
> That patch has been updated in linux-next recently
On Mon, Nov 25, 2013 at 03:57:40PM +0200, Boaz Harrosh wrote:
> On 11/25/2013 03:25 PM, Yuanhan Liu wrote:
> >
> > Hi Boaz,
> >
> > We are running an 0day kernel testing system. We will test all developers'
> > tree we tracked in our system automatically. A
On Mon, Nov 25, 2013 at 12:43:42PM +0200, Boaz Harrosh wrote:
> On 11/22/2013 08:02 AM, Yuanhan Liu wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit 20545536cd8ea949c61527b6395ec8c0d2c237b1
> > Author: Boaz H
Greetings,
We got the following warning:
[ 25.040056] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 25.047312] EDD information not available.
[ 25.637680] [ cut here ]
[ 25.643383] WARNING: CPU: 10 PID: 1 at
/c/kernel-tests/src/x86_64/net/core/dev.
Remove CONFIG_USE_GENERIC_SMP_HELPERS left by commit
0a06ff06("kernel: remove CONFIG_USE_GENERIC_SMP_HELPERS").
Cc: Christoph Hellwig
Cc: Andrew Morton
Signed-off-by: Yuanhan Liu
---
drivers/block/null_blk.c |8
net/Kconfig |4 ++--
2 files changed, 6
On Wed, Nov 13, 2013 at 09:40:48AM -0800, John Stultz wrote:
> On 11/13/2013 01:14 AM, Yuanhan Liu wrote:
> > Hi,
> >
> > FYI, we found some performance regressions caused by commit 1ca7d67c
> > ("seqcount: Add lockdep functionality to seqcount/seqlock struc
On Tue, Nov 05, 2013 at 11:10:43AM +0800, Yuanhan Liu wrote:
> On Mon, Nov 04, 2013 at 05:44:00PM -0800, Tim Chen wrote:
> > On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote:
> > > On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
> > > > On
On Mon, Nov 04, 2013 at 05:44:00PM -0800, Tim Chen wrote:
> On Mon, 2013-11-04 at 11:59 +0800, Yuanhan Liu wrote:
> > On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
> > > On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
> > > > On Fri, Nov 01,
On Fri, Nov 01, 2013 at 08:15:13PM -0700, Davidlohr Bueso wrote:
> On Fri, 2013-11-01 at 18:16 +0800, Yuanhan Liu wrote:
> > On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
> > >
> > > * Yuanhan Liu wrote:
> > >
> > > > > Btw
On Fri, Nov 01, 2013 at 11:04:40AM -0700, Linus Torvalds wrote:
> On Fri, Nov 1, 2013 at 12:54 AM, Yuanhan Liu
> wrote:
> > @@ -67,19 +67,7 @@ static struct kmem_cache *anon_vma_chain_cachep;
> >
> > static inline struct anon_vma *anon_vma_alloc(void)
> > {
> &g
On Fri, Nov 01, 2013 at 11:22:24AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 01, 2013 at 05:38:44PM +0800, Yuanhan Liu wrote:
> > On Fri, Nov 01, 2013 at 09:43:29AM +0100, Peter Zijlstra wrote:
> > > On Fri, Nov 01, 2013 at 03:54:24PM +0800, Yuanhan Liu wrote:
> > > >
On Fri, Nov 01, 2013 at 01:07:45PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 01, 2013 at 07:44:29PM +0800, Yuanhan Liu wrote:
> > commit 012f18004da33ba672e3c60838cc4898126174d3
> > Author: Rik van Riel
> > Date: Mon Aug 9 17:18:40 2010 -0700
> >
> >
On Fri, Nov 01, 2013 at 11:15:14AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 01, 2013 at 06:07:07PM +0800, Yuanhan Liu wrote:
> > > I also want to point out that lately we've seen several changes sent
> > > out that relax locking with no accompanying explanation of why
On Fri, Nov 01, 2013 at 09:21:46AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > > Btw., another _really_ interesting comparison would be against
> > > the latest rwsem patches. Mind doing such a comparison?
> >
> > Sure. Where can I get it?
On Fri, Nov 01, 2013 at 02:22:25AM -0700, Michel Lespinasse wrote:
> On Fri, Nov 1, 2013 at 1:43 AM, Peter Zijlstra wrote:
> > AFAICT this isn't correct at all. We used to protect the vma interval
> > tree with the root lock, now we don't. All we've got left is the
> > mmap_sem, but anon_vma chain
On Fri, Nov 01, 2013 at 09:43:29AM +0100, Peter Zijlstra wrote:
> On Fri, Nov 01, 2013 at 03:54:24PM +0800, Yuanhan Liu wrote:
> > @@ -497,15 +495,20 @@ static void vma_rb_erase(struct vm_area_struct *vma,
> > struct rb_root *root)
> > * anon_vma_interval
On Fri, Nov 01, 2013 at 09:01:36AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > Patch 1 turns locking the anon_vma's root to locking itself to let it be
> > a per anon_vma lock, which would reduce contentions.
> >
> > In the same time, lock ra
ijlstra (1):
mm/rmap: cleanup unnecessary code
Yuanhan Liu (2):
mm/rmap: per anon_vma lock
mm/rmap.c: move anon_vma initialization code into anon_vma_ctor
include/linux/mmu_notifier.h |2 +-
include/linux/rmap.h | 19 ++---
mm/huge_memory.c |4 +-
-26.7%
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Michel Lespinasse
Signed-off-by: Ingo Molnar
Signed-off-by: Yuanhan Liu
---
include/linux/mmu_notifier.h |2 +-
include/linux/rmap.h | 19 +--
mm/huge_memory.c |4
: Linus Torvalds
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Michel Lespinasse
Signed-off-by: Yuanhan Liu
---
include/linux/rmap.h | 12
mm/huge_memory.c |4 +-
mm/mmap.c| 46 +++---
mm/rmap
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Peter Zijlstra
Cc: Michel Lespinasse
Signed-off-by: Yuanhan Liu
---
mm/rmap.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/mm/rmap.c b/mm/rmap.c
index 246b5fe
From: Peter Zijlstra
Quot from Peter: [ edited by Yuanhan Liu ]
You can remove all that -- all that trickery was only needed because the
lock could sleep;
Cc: Ingo Molnar
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Rik van Riel
Cc: Michel Lespinasse
Signed-off-by: Peter Zijlstra
On Wed, Sep 25, 2013 at 09:38:19AM -0700, tip-bot for Peter Zijlstra wrote:
> Commit-ID: ea8117478918a4734586d35ff530721b682425be
> Gitweb: http://git.kernel.org/tip/ea8117478918a4734586d35ff530721b682425be
> Author: Peter Zijlstra
> AuthorDate: Wed, 11 Sep 2013 12:43:13 +0200
> Committer
On Fri, Sep 20, 2013 at 06:46:59AM -0700, tip-bot for Vladimir Davydov wrote:
> Commit-ID: 7e3115ef5149fc502e3a2e80719dba54a8e7409d
> Gitweb: http://git.kernel.org/tip/7e3115ef5149fc502e3a2e80719dba54a8e7409d
> Author: Vladimir Davydov
> AuthorDate: Sat, 14 Sep 2013 19:39:46 +0400
> Commi
On Sat, May 25, 2013 at 12:31:43AM -0700, Yinghai Lu wrote:
> On Fri, May 24, 2013 at 9:30 PM, Yuanhan Liu
> wrote:
> > Commit 8d57470d introduced a kernel panic while setting mem=2G at
> > boot time, and commit c9b3234a6 turns the the kernel panic to hang.
> >
> >
to following will make this issue gone:
if(address >= end && !spliting) {
...
}
Reported-by: LKP
CC: For 3.9+
Cc: H. Peter Anvin
Cc: Yinghai Lu
Bisected-by: "Xie, ChanglongX"
Signed-off-by: Yuanhan Liu
---
I reported this panic regression
Commit-ID: 41ef8f826692c8f65882bec0a8211bd4d1d2d19a
Gitweb: http://git.kernel.org/tip/41ef8f826692c8f65882bec0a8211bd4d1d2d19a
Author: Yuanhan Liu
AuthorDate: Fri, 1 Feb 2013 18:59:16 +0800
Committer: Ingo Molnar
CommitDate: Tue, 19 Feb 2013 08:43:39 +0100
rwsem-spinlock: Implement
Commit-ID: 0be5c8ff58cf7a66019af2f1236daff731ed318c
Gitweb: http://git.kernel.org/tip/0be5c8ff58cf7a66019af2f1236daff731ed318c
Author: Yuanhan Liu
AuthorDate: Thu, 24 Jan 2013 17:22:44 +0800
Committer: Ingo Molnar
CommitDate: Tue, 19 Feb 2013 08:42:37 +0100
locking/stat: Fix a typo
s
Commit-ID: 5dae63c442131f1b0a66abd43fdc861031f13ca6
Gitweb: http://git.kernel.org/tip/5dae63c442131f1b0a66abd43fdc861031f13ca6
Author: Yuanhan Liu
AuthorDate: Fri, 1 Feb 2013 18:59:16 +0800
Committer: Ingo Molnar
CommitDate: Mon, 18 Feb 2013 10:10:21 +0100
rwsem-spinlock: Implement
Hi Ingo,
Ping...
On Fri, Feb 01, 2013 at 06:59:16PM +0800, Yuanhan Liu wrote:
> We(Linux Kernel Performance project) found a regression introduced by
> commit 5a50508, which just convert all mutex lock to rwsem write lock.
> The semantics is same, but the results is quite huge in s
PU is much busier with this patch.
v2: make it stealable at __down_write_trylock as well, pointed by Michel
Reported-by: LKP project
Suggested-by: Ingo Molnar
Cc: David Howells
Cc: Michel Lespinasse
Signed-off-by: Yuanhan Liu
---
lib/rwsem-spinloc
On Thu, Jan 31, 2013 at 12:22:52PM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > > or whether the lock hold times could be reduced drastically
> >
> > I also found one, but it doesn't sound like the one will
> > reduce lock hold times
On Thu, Jan 31, 2013 at 10:18:18PM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
> > >
> > > * Yuanhan Liu wrote:
> > >
> > > > BTW, mind to tell a nice test case fo
On Thu, Jan 31, 2013 at 02:12:28PM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > BTW, mind to tell a nice test case for mmap_sem?
>
> this one was write-hitting on mmap_sem pretty hard, last I
> checked:
>
> http://people.redhat.com/mingo/threaded
On Thu, Jan 31, 2013 at 03:57:51AM -0800, Michel Lespinasse wrote:
> On Wed, Jan 30, 2013 at 1:14 AM, Yuanhan Liu
> wrote:
> > We(Linux Kernel Performance project) found a regression introduced by
> > commit 5a50508, which just convert all mutex lock to rwsem write lock.
> &g
On Thu, Jan 31, 2013 at 11:45:41AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > > > output with this patch:
> > > > ---
> > > > cpu 00: 0 0 ... 1 1 2 1 1 1 2 1 1 1 1 3
> > > &
On Thu, Jan 31, 2013 at 10:39:31AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > We(Linux Kernel Performance project) found a regression introduced by
> > commit 5a50508, which just convert all mutex lock to rwsem write lock.
> > The semantics is same, bu
Fix the wrong comment about the return value of clone_uts_ns()
Cc: Serge Hallyn
Signed-off-by: Yuanhan Liu
---
kernel/utsname.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/utsname.c b/kernel/utsname.c
index 08b197e..a47fc5d 100644
--- a/kernel/utsname.c
put get/get_uts() into CONFIG_PROC_SYSCTL code block as they are used
only when CONFIG_PROC_SYSCTL is enabled.
Signed-off-by: Yuanhan Liu
---
kernel/utsname_sysctl.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/kernel/utsname_sysctl.c b/kernel/utsname_sysctl.c
We can use user_ns, which is also assigned from task_cred_xxx(tsk,
user_ns), at the beginning of copy_namespaces().
Cc: Serge Hallyn
Signed-off-by: Yuanhan Liu
---
kernel/nsproxy.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
On Tue, Jan 29, 2013 at 10:12:45AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > On Tue, Jan 29, 2013 at 09:44:00AM +0100, Ingo Molnar wrote:
> > >
> > > * Yuanhan Liu wrote:
> > >
> > > > [...]
> > >
> > &g
1 1 1 1 2 2
cpu 15: 0 0 ... 2 0 0 1 0 1 1 1 1 1 2 2
Where you can see that CPU is much busier with this patch.
Suggested-by: Ingo Molnar
Cc: David Howells
Signed-off-by: Yuanha
On Tue, Jan 29, 2013 at 09:44:00AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > [...]
>
> Very nice measurements and analysis, thanks!
>
> > As stated above, anybody can have a chance to own the lock in
> > mutex once somebody release the lock.
Hi,
Here we, LKP(Linux Kernel Performance, a project to do performance
benchmark testing for Linux kernel, and try to find and fix the
performance regressions), found a 10%-20% performance regression
of aim7 benchmark introduced by commit 5a50508: "mm/rmap: Convert
the struct anon_vma::mutex to an
Commit-ID: 5b43715b9d27e4e6620264113169bb8e4e607205
Gitweb: http://git.kernel.org/tip/5b43715b9d27e4e6620264113169bb8e4e607205
Author: Yuanhan Liu
AuthorDate: Thu, 24 Jan 2013 17:22:44 +0800
Committer: Ingo Molnar
CommitDate: Thu, 24 Jan 2013 10:59:43 +0100
locking/stat: Fix a typo
s
On Thu, Jan 24, 2013 at 11:14:50AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > On Thu, Jan 24, 2013 at 10:58:07AM +0100, Ingo Molnar wrote:
> > >
> > > * Yuanhan Liu wrote:
> > >
> > > > Use spin_[un]lock instead of arch
On Thu, Jan 24, 2013 at 10:58:07AM +0100, Ingo Molnar wrote:
>
> * Yuanhan Liu wrote:
>
> > Use spin_[un]lock instead of arch_spin_[un]lock in mutex-debug.h so
> > that we can collect the lock statistics of spin_lock_mutex from
> > /proc/lock_stat.
> >
>
1 - 100 of 160 matches
Mail list logo
