On 6/2/16 10:13 PM, Serge E. Hallyn wrote:
On Wed, Jun 01, 2016 at 02:03:02PM +0800, Rui Teng wrote:
Sparse spits out the following warning:
security/commoncap.c:989:41: warning: dubious: !x | y
Bitwise and logical are equivalent here, but logical was intended.
Replacing the bit-wise
.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
security/commoncap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index e7fadde..8f6fb24 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -976,7
On 3/9/16 8:10 PM, Anshuman Khandual wrote:
This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
It also implements a new function 'pte_huge' which is required by
function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
specific functions 'huge_pte_alloc' and 'huge_pte_offset'
On 4/25/16 1:21 PM, js1...@gmail.com wrote:
From: Joonsoo Kim
Attached cover-letter:
This series try to solve problems of current CMA implementation.
CMA is introduced to provide physically contiguous pages at runtime
without exclusive reserved memory area. But,
eported by scripts/checkpatch.pl.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
drivers/input/keyboard/twl4030_keypad.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_
On 4/25/16 1:21 PM, js1...@gmail.com wrote:
From: Joonsoo Kim
Some of zone threshold depends on number of managed pages in the zone.
When memory is going on/offline, it can be changed and we need to
adjust them.
This patch add recalculation to appropriate places and
ed
by the kernel for all supported memory contexts. This helps prevent
the possibility of getting return codes similar to H_RESOURCE for
H_PROTECT hcalls for conflicting HPTE entries.
Signed-off-by: Anshuman Khandual <khand...@linux.vnet.ibm.com>
Signed-off-by: Rui Teng <rui.t...@linux.v
Clear all the errors and also some warnings reported by checkpatch.pl scripts
for file tools/perf/util/header.c
And replace __attribute__((weak)) to __weak definition from
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
tools/perf/util/header.
Replace __attribute__((weak)) to __weak definition
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
tools/perf/util/header.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 8d76d55..576addd
Clear all the errors and also some warnings reported by checkpatch.pl scripts
for file tools/perf/util/header.c
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
tools/perf/util/header.c | 60 ++--
1 file changed, 33 insertions(+), 27 del
'.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
tools/perf/Makefile.perf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2d90875..9c1dac6 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefil
On 31/01/2017 5:11 PM, Michael Ellerman wrote:
Rui Teng <rui.t...@linux.vnet.ibm.com> writes:
The offset of hugepage block will not be 16G, if the expected
page is more than one. Calculate the totol size instead of the
hardcode value.
I assume you found this by code insp
There are three #ifdef CONFIG_PPC_BOOK3E sections in nohash/64/pgtable.h.
And there should be no configurations possible which use nohash/64/pgtable.h
but don't also enable CONFIG_PPC_BOOK3E.
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Rui Teng <rui.t...@linux.vne
ed
by the kernel for all supported memory contexts. This helps prevent
the possibility of getting return codes similar to H_RESOURCE for
H_PROTECT hcalls for conflicting HPTE entries.
Signed-off-by: Anshuman Khandual <khand...@linux.vnet.ibm.com>
Signed-off-by: Rui Teng <rui.t...@linux.v
On 9/1/16 11:46 PM, Thiago Jung Bauermann wrote:
Am Freitag, 26 August 2016, 11:50:10 schrieb Rui Teng:
The same logic appears twice and should probably be pulled out into a
function.
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Rui Teng <rui.t...@linux.vne
The same logic appears twice and should probably be pulled out into a function.
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
Changes in V2:
- Change function to static and inline
- Use #else block to define an empty s
On 9/14/16 1:32 AM, Dave Hansen wrote:
On 09/13/2016 01:39 AM, Rui Teng wrote:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..64b5f81 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1442,7 +1442,7 @@ static int free_pool_huge_page(struct hstate *h,
nodemask_t *nodes_allowed,
static
tation fault
Reported-by: Santhosh G <santh...@in.ibm.com>
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..64b5f81 100644
--- a/mm/hugetlb.c
+++ b/mm/hu
On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
The huge page size could be 16G(0x4) on ppc64 architecture, and it will
cause an overflow on unsigned long data type(0x).
Huh? ppc64 is 64-bit system and sizeof(void
ink it needs to change the data type from unsigned long to u64. But it will
cause a lot of functions and data structures changed. Any comments and
suggestions?
Thanks!
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
include/linux/hugetlb.h | 4 ++--
1 file changed, 2 inserti
On 9/13/16 7:40 PM, Kirill A. Shutemov wrote:
On Tue, Sep 13, 2016 at 07:21:07PM +0800, Rui Teng wrote:
On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
The huge page size could be 16G(0x4) on ppc64 architecture, and it will
cause
On 9/23/16 7:03 PM, Gerald Schaefer wrote:
On Fri, 23 Sep 2016 14:40:33 +0800
Rui Teng <rui.t...@linux.vnet.ibm.com> wrote:
On 9/22/16 5:51 PM, Michal Hocko wrote:
On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or
On 9/20/16 10:53 PM, Dave Hansen wrote:
On 09/20/2016 07:45 AM, Rui Teng wrote:
On 9/17/16 12:25 AM, Dave Hansen wrote:
That's an interesting data point, but it still doesn't quite explain
what is going on.
It seems like there might be parts of gigantic pages that have
PageHuge() set on tail
On 9/21/16 8:35 PM, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb page
with a size > memory block size.
When no
On 9/22/16 5:51 PM, Michal Hocko wrote:
On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb
n...@au.ibm.com>
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
.../testing/selftests/powerpc/benchmarks/Makefile | 2 +-
.../selftests/powerpc/benchmarks/null_syscall.c| 157 +
2 files changed, 158 insertions(+), 1 deletion(-)
create mode 100644 tools/t
On 9/17/16 12:25 AM, Dave Hansen wrote:
That's an interesting data point, but it still doesn't quite explain
what is going on.
It seems like there might be parts of gigantic pages that have
PageHuge() set on tail pages, while other parts don't. If that's true,
we have another bug and your
On 9/15/16 12:37 AM, Dave Hansen wrote:
On 09/14/2016 09:33 AM, Rui Teng wrote:
How about return the size of page freed from dissolve_free_huge_page(),
and jump such step on pfn?
That would be a nice improvement.
But, as far as describing the initial problem, can you explain how the
tail
The same logic appears twice and should probably be pulled out into a function.
Suggested-by: Michael Ellerman <m...@ellerman.id.au>
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 45 +
1 file
n...@au.ibm.com>
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
.../testing/selftests/powerpc/benchmarks/Makefile | 2 +-
.../selftests/powerpc/benchmarks/null_syscall.c| 157 +
2 files changed, 158 insertions(+), 1 deletion(-)
create mode 100644 tools/t
The offset of hugepage block will not be 16G, if the expected
page is more than one. Calculate the totol size instead of the
hardcode value.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
This patch sets memory to zero directly to avoid unnecessary shift and
bitwise operations on bool type, which can fix a sparse warning and also
improve performance.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
drivers/staging/wilc1000/host_interface.c | 7 +++
1 file chan
Comparing two user space addresses to avoid sparse error:
drivers/staging//lustre/lnet/selftest/conrpc.c:490:30: error:
incompatible types in comparison expression (different address spaces)
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
drivers/staging/lustre/lnet/selftest/co
On 12/07/2017 1:04 AM, Greg Kroah-Hartman wrote:
On Mon, Jul 10, 2017 at 04:57:31PM +0800, Rui Teng wrote:
This patch sets memory to zero directly to avoid unnecessary shift and
bitwise operations on bool type, which can fix a sparse warning and also
improve performance.
It does? How did you
This is a patch to the spk_ttyio.c file which fixes up the indent error
reported by the checkpatch.pl tool.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
drivers/staging/speakup/spk_ttyio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/s
This is a patch to the spk_ttyio.c file which fixes up the problems
reported by the checkpatch.pl tool.
Signed-off-by: Rui Teng <rui.t...@linux.vnet.ibm.com>
---
drivers/staging/speakup/spk_ttyio.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/s
Comparing two user space addresses to avoid sparse error:
drivers/staging//lustre/lnet/selftest/conrpc.c:490:30: error:
incompatible types in comparison expression (different address spaces)
Signed-off-by: Rui Teng
---
drivers/staging/lustre/lnet/selftest/conrpc.c | 5 ++---
1 file changed, 2
This patch sets memory to zero directly to avoid unnecessary shift and
bitwise operations on bool type, which can fix a sparse warning and also
improve performance.
Signed-off-by: Rui Teng
---
drivers/staging/wilc1000/host_interface.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions
On 12/07/2017 1:04 AM, Greg Kroah-Hartman wrote:
On Mon, Jul 10, 2017 at 04:57:31PM +0800, Rui Teng wrote:
This patch sets memory to zero directly to avoid unnecessary shift and
bitwise operations on bool type, which can fix a sparse warning and also
improve performance.
It does? How did you
On 9/21/16 8:35 PM, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb page
with a size > memory block size.
When no
On 9/22/16 5:51 PM, Michal Hocko wrote:
On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing exception when trying to set a memory
block offline that is part (but not the first part) of a hugetlb
From: Anton Blanchard
Pull in a version of Anton's null_syscall benchmark:
http://ozlabs.org/~anton/junkcode/null_syscall.c
Into tools/testing/selftests/powerpc/benchmarks.
Suggested-by: Michael Ellerman
Signed-off-by: Anton Blanchard
Signed-off-by: Rui Teng
---
.../testing/selftests
This is a patch to the spk_ttyio.c file which fixes up the indent error
reported by the checkpatch.pl tool.
Signed-off-by: Rui Teng
---
drivers/staging/speakup/spk_ttyio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/speakup/spk_ttyio.c
b/drivers/staging
This is a patch to the spk_ttyio.c file which fixes up the problems
reported by the checkpatch.pl tool.
Signed-off-by: Rui Teng
---
drivers/staging/speakup/spk_ttyio.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/speakup/spk_ttyio.c
b/drivers
On 9/17/16 12:25 AM, Dave Hansen wrote:
That's an interesting data point, but it still doesn't quite explain
what is going on.
It seems like there might be parts of gigantic pages that have
PageHuge() set on tail pages, while other parts don't. If that's true,
we have another bug and your
On 9/20/16 10:53 PM, Dave Hansen wrote:
On 09/20/2016 07:45 AM, Rui Teng wrote:
On 9/17/16 12:25 AM, Dave Hansen wrote:
That's an interesting data point, but it still doesn't quite explain
what is going on.
It seems like there might be parts of gigantic pages that have
PageHuge() set on tail
There are three #ifdef CONFIG_PPC_BOOK3E sections in nohash/64/pgtable.h.
And there should be no configurations possible which use nohash/64/pgtable.h
but don't also enable CONFIG_PPC_BOOK3E.
Suggested-by: Michael Ellerman
Signed-off-by: Rui Teng
---
arch/powerpc/include/asm/nohash/64
The same logic appears twice and should probably be pulled out into a function.
Suggested-by: Michael Ellerman
Signed-off-by: Rui Teng
---
arch/powerpc/mm/hash_utils_64.c | 45 +
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/arch
The offset of hugepage block will not be 16G, if the expected
page is more than one. Calculate the totol size instead of the
hardcode value.
Signed-off-by: Rui Teng
---
arch/powerpc/mm/hash_utils_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm
On 31/01/2017 5:11 PM, Michael Ellerman wrote:
Rui Teng writes:
The offset of hugepage block will not be 16G, if the expected
page is more than one. Calculate the totol size instead of the
hardcode value.
I assume you found this by code inspection and not by triggering an
actual bug?
Yes
On 9/14/16 1:32 AM, Dave Hansen wrote:
On 09/13/2016 01:39 AM, Rui Teng wrote:
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..64b5f81 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1442,7 +1442,7 @@ static int free_pool_huge_page(struct hstate *h,
nodemask_t *nodes_allowed,
static
On 9/15/16 12:37 AM, Dave Hansen wrote:
On 09/14/2016 09:33 AM, Rui Teng wrote:
How about return the size of page freed from dissolve_free_huge_page(),
and jump such step on pfn?
That would be a nice improvement.
But, as far as describing the initial problem, can you explain how the
tail
ted memory contexts. This helps prevent
the possibility of getting return codes similar to H_RESOURCE for
H_PROTECT hcalls for conflicting HPTE entries.
Signed-off-by: Anshuman Khandual
Signed-off-by: Rui Teng
---
- Tested on both POWER8 LE and BE platforms
Changes in V3:
- Use u32 and u64 to store t
On 9/1/16 11:46 PM, Thiago Jung Bauermann wrote:
Am Freitag, 26 August 2016, 11:50:10 schrieb Rui Teng:
The same logic appears twice and should probably be pulled out into a
function.
Suggested-by: Michael Ellerman
Signed-off-by: Rui Teng
---
arch/powerpc/mm/hash_utils_64.c | 45
The same logic appears twice and should probably be pulled out into a function.
Suggested-by: Michael Ellerman
Signed-off-by: Rui Teng
---
Changes in V2:
- Change function to static and inline
- Use #else block to define an empty static inline function
---
arch/powerpc/mm/hash_utils_64.c | 55
-by: Santhosh G
Signed-off-by: Rui Teng
---
mm/hugetlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 87e11d8..64b5f81 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1442,7 +1442,7 @@ static int free_pool_huge_page(struct hstate *h,
nodemask_t
ink it needs to change the data type from unsigned long to u64. But it will
cause a lot of functions and data structures changed. Any comments and
suggestions?
Thanks!
Signed-off-by: Rui Teng
---
include/linux/hugetlb.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/incl
On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
The huge page size could be 16G(0x4) on ppc64 architecture, and it will
cause an overflow on unsigned long data type(0x).
Huh? ppc64 is 64-bit system and sizeof(void
On 9/13/16 7:40 PM, Kirill A. Shutemov wrote:
On Tue, Sep 13, 2016 at 07:21:07PM +0800, Rui Teng wrote:
On 9/13/16 5:32 PM, Kirill A. Shutemov wrote:
On Tue, Sep 13, 2016 at 05:26:05PM +0800, Rui Teng wrote:
The huge page size could be 16G(0x4) on ppc64 architecture, and it will
cause
On 9/23/16 7:03 PM, Gerald Schaefer wrote:
On Fri, 23 Sep 2016 14:40:33 +0800
Rui Teng wrote:
On 9/22/16 5:51 PM, Michal Hocko wrote:
On Wed 21-09-16 14:35:34, Gerald Schaefer wrote:
dissolve_free_huge_pages() will either run into the VM_BUG_ON() or a
list corruption and addressing
From: Anton Blanchard
Pull in a version of Anton's null_syscall benchmark:
http://ozlabs.org/~anton/junkcode/null_syscall.c
Into tools/testing/selftests/powerpc/benchmarks.
Suggested-by: Michael Ellerman
Signed-off-by: Anton Blanchard
Signed-off-by: Rui Teng
---
.../testing/selftests
On 4/25/16 1:21 PM, js1...@gmail.com wrote:
From: Joonsoo Kim
Some of zone threshold depends on number of managed pages in the zone.
When memory is going on/offline, it can be changed and we need to
adjust them.
This patch add recalculation to appropriate places and clean-up
related function
eported by scripts/checkpatch.pl.
Signed-off-by: Rui Teng
---
drivers/input/keyboard/twl4030_keypad.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/input/keyboard/twl4030_keypad.c
b/drivers/input/keyboard/twl4030_keypad.c
index bbcccd6..8d061c0 100
On 4/25/16 1:21 PM, js1...@gmail.com wrote:
From: Joonsoo Kim
Attached cover-letter:
This series try to solve problems of current CMA implementation.
CMA is introduced to provide physically contiguous pages at runtime
without exclusive reserved memory area. But, current implementation
works
On 3/9/16 8:10 PM, Anshuman Khandual wrote:
This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
It also implements a new function 'pte_huge' which is required by
function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
specific functions 'huge_pte_alloc' and 'huge_pte_offset'
Clear all the errors and also some warnings reported by checkpatch.pl scripts
for file tools/perf/util/header.c
Signed-off-by: Rui Teng
---
tools/perf/util/header.c | 60 ++--
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/tools/perf
Replace __attribute__((weak)) to __weak definition
Signed-off-by: Rui Teng
---
tools/perf/util/header.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 8d76d55..576addd 100644
--- a/tools/perf/util/header.c
+++ b
ted memory contexts. This helps prevent
the possibility of getting return codes similar to H_RESOURCE for
H_PROTECT hcalls for conflicting HPTE entries.
Signed-off-by: Anshuman Khandual
Signed-off-by: Rui Teng
---
- Tested on both POWER8 LE and BE platforms
Changes in V3:
- Use u32 and u64 to store t
Clear all the errors and also some warnings reported by checkpatch.pl scripts
for file tools/perf/util/header.c
And replace __attribute__((weak)) to __weak definition from
Signed-off-by: Rui Teng
---
tools/perf/util/header.c | 44 ++--
1 file changed, 26
'.
Signed-off-by: Rui Teng
---
tools/perf/Makefile.perf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2d90875..9c1dac6 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -165,7 +165,7
.
Signed-off-by: Rui Teng
---
security/commoncap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/security/commoncap.c b/security/commoncap.c
index e7fadde..8f6fb24 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -976,7 +976,7 @@ int cap_task_prctl(int option
On 6/2/16 10:13 PM, Serge E. Hallyn wrote:
On Wed, Jun 01, 2016 at 02:03:02PM +0800, Rui Teng wrote:
Sparse spits out the following warning:
security/commoncap.c:989:41: warning: dubious: !x | y
Bitwise and logical are equivalent here, but logical was intended.
Replacing the bit-wise
Commit-ID: 11196b79164c95b8e5968ff63fa6b59536c9748f
Gitweb: http://git.kernel.org/tip/11196b79164c95b8e5968ff63fa6b59536c9748f
Author: Rui Teng <rui.t...@linux.vnet.ibm.com>
AuthorDate: Wed, 10 Aug 2016 16:49:08 +0800
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
Com
Commit-ID: 11d8f870c8eb8dd41ade688fbad6946ad69243fe
Gitweb: http://git.kernel.org/tip/11d8f870c8eb8dd41ade688fbad6946ad69243fe
Author: Rui Teng <rui.t...@linux.vnet.ibm.com>
AuthorDate: Thu, 28 Jul 2016 10:05:57 +0800
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
Com
Commit-ID: 11196b79164c95b8e5968ff63fa6b59536c9748f
Gitweb: http://git.kernel.org/tip/11196b79164c95b8e5968ff63fa6b59536c9748f
Author: Rui Teng
AuthorDate: Wed, 10 Aug 2016 16:49:08 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 23 Aug 2016 15:37:33 -0300
perf tools: Skip
Commit-ID: 11d8f870c8eb8dd41ade688fbad6946ad69243fe
Gitweb: http://git.kernel.org/tip/11d8f870c8eb8dd41ade688fbad6946ad69243fe
Author: Rui Teng
AuthorDate: Thu, 28 Jul 2016 10:05:57 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 23 Aug 2016 15:37:33 -0300
perf tools: Use
76 matches
Mail list logo