On Wed, Sep 26, 2012 at 11:50 AM, Minchan Kim wrote:
> lib/Kconfig |2 +
> lib/Makefile |1 +
> lib/zsmalloc/Kconfig | 18 +
> lib/zsmalloc/Makefile|1 +
> lib/zsmalloc/zsmalloc.c
On Wed, Sep 26, 2012 at 11:50 AM, Minchan Kim minc...@kernel.org wrote:
lib/Kconfig |2 +
lib/Makefile |1 +
lib/zsmalloc/Kconfig | 18 +
lib/zsmalloc/Makefile|1 +
portable. In addition, many embedded
product uses zram in real practive so I think there is no reason
to prevent promotion now.
Cc: Seth Jennings sjenn...@linux.vnet.ibm.com
Cc: Nitin Gupta ngu...@vflare.org
Signed-off-by: Minchan Kim minc...@kernel.org
FWIW,
Acked-by: Pekka Enberg penb
On Mon, Sep 24, 2012 at 8:13 PM, Ezequiel Garcia wrote:
> Will you pick this (and the rest of cleanup patches)
> for v3.7 pull request?
> Or is there anything for me to redo?
I merged all the patches except for the last one which conflicts with
the kmem/memcg changes.
--
To unsubscribe from this
and to be used by memdup_user and strndup_user.
>
> Cc: Pekka Enberg
> Signed-off-by: Ezequiel Garcia
> ---
> mm/util.c | 11 ---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/mm/util.c b/mm/util.c
> index dc3036c..48d3ff8b 100644
> --- a/mm/util.c
and strndup_user.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
---
mm/util.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index dc3036c..48d3ff8b 100644
--- a/mm/util.c
+++ b/mm/util.c
On Mon, Sep 24, 2012 at 8:13 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Will you pick this (and the rest of cleanup patches)
for v3.7 pull request?
Or is there anything for me to redo?
I merged all the patches except for the last one which conflicts with
the kmem/memcg changes.
--
To
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
>> On Mon, 24 Sep 2012, Glauber Costa wrote:
>>
>>> The reason I say it is orthogonal, is that people will still want to see
>>> their caches in /proc/slabinfo, regardless of wherever else they'll be.
>>> It was a requirement from Pekka in one of
On 09/24/2012 05:56 PM, Christoph Lameter wrote:
On Mon, 24 Sep 2012, Glauber Costa wrote:
The reason I say it is orthogonal, is that people will still want to see
their caches in /proc/slabinfo, regardless of wherever else they'll be.
It was a requirement from Pekka in one of the first times
On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo wrote:
> Not necessarily disagreeing, but I don't think it's helpful to set the
> bar impossibly high. Even static_key doesn't have "exactly *zero*"
> impact. Let's stick to as minimal as possible when not in use and
> reasonable in use.
For
On Fri, 21 Sep 2012, Glauber Costa wrote:
> > We should assume that most distributions enable CONFIG_MEMCG_KMEM,
> > right? Therfore, any performance impact should be dependent on whether
> > or not kmem memcg is *enabled* at runtime or not.
> >
> > Can we use the "static key" thingy introduced
Hi Glauber,
On Tue, Sep 18, 2012 at 5:11 PM, Glauber Costa wrote:
> This is a followup to the previous kmem series. I divided them logically
> so it gets easier for reviewers. But I believe they are ready to be merged
> together (although we can do a two-pass merge if people would prefer)
>
>
On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa wrote:
>>> index f2d760c..18de3f6 100644
>>> --- a/mm/slab.c
>>> +++ b/mm/slab.c
>>> @@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
>>> * Free an object which was previously allocated from this
>>> * cache.
>>> */
>>> -void
On Tue, Sep 18, 2012 at 5:12 PM, Glauber Costa wrote:
> diff --git a/mm/slab.c b/mm/slab.c
> index e2cf984..f2d760c 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -4141,8 +4141,19 @@ static int do_tune_cpucache(struct kmem_cache *cachep,
> int limit,
> static int enable_cpucache(struct
Hi Irina,
On Fri, Sep 21, 2012 at 1:13 AM, Irina Tirdea wrote:
> diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
> index b442ee4..c5b4632 100644
> --- a/tools/perf/util/map.c
> +++ b/tools/perf/util/map.c
> @@ -59,7 +59,8 @@ struct map *map__new(struct list_head *dsos__list, u64
>
Hi Irina,
On Fri, Sep 21, 2012 at 1:13 AM, Irina Tirdea irina.tir...@gmail.com wrote:
diff --git a/tools/perf/util/map.c b/tools/perf/util/map.c
index b442ee4..c5b4632 100644
--- a/tools/perf/util/map.c
+++ b/tools/perf/util/map.c
@@ -59,7 +59,8 @@ struct map *map__new(struct list_head
On Tue, Sep 18, 2012 at 5:12 PM, Glauber Costa glom...@parallels.com wrote:
diff --git a/mm/slab.c b/mm/slab.c
index e2cf984..f2d760c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4141,8 +4141,19 @@ static int do_tune_cpucache(struct kmem_cache *cachep,
int limit,
static int
On Wed, Sep 19, 2012 at 10:42 AM, Glauber Costa glom...@parallels.com wrote:
index f2d760c..18de3f6 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3938,9 +3938,12 @@ EXPORT_SYMBOL(__kmalloc);
* Free an object which was previously allocated from this
* cache.
*/
-void
Hi Glauber,
On Tue, Sep 18, 2012 at 5:11 PM, Glauber Costa glom...@parallels.com wrote:
This is a followup to the previous kmem series. I divided them logically
so it gets easier for reviewers. But I believe they are ready to be merged
together (although we can do a two-pass merge if people
On Fri, 21 Sep 2012, Glauber Costa wrote:
We should assume that most distributions enable CONFIG_MEMCG_KMEM,
right? Therfore, any performance impact should be dependent on whether
or not kmem memcg is *enabled* at runtime or not.
Can we use the static key thingy introduced by tracing
On Fri, Sep 21, 2012 at 11:07 PM, Tejun Heo t...@kernel.org wrote:
Not necessarily disagreeing, but I don't think it's helpful to set the
bar impossibly high. Even static_key doesn't have exactly *zero*
impact. Let's stick to as minimal as possible when not in use and
reasonable in use.
For
On Tue, 18 Sep 2012, Dave Jones wrote:
>> It doesn't seem worth adding a new taint flag for this, so just re-use
>> the one from 'bad page'
>>
>> Signed-off-by: Dave Jones
On Tue, Sep 18, 2012 at 11:19 PM, David Rientjes wrote:
> Acked-by: David Rientjes
Applied, thanks!
--
To unsubscribe
On Tue, 11 Sep 2012, Christoph Lameter wrote:
> On Tue, 11 Sep 2012, Stephen Rothwell wrote:
>
> > After merging the final tree, today's linux-next build (sparc64 defconfig)
> > produced this warning:
> >
> > mm/slab.c:808:13: warning: '__slab_error' defined but not used
> > [-Wunused-function]
On Tue, 11 Sep 2012, Christoph Lameter wrote:
On Tue, 11 Sep 2012, Stephen Rothwell wrote:
After merging the final tree, today's linux-next build (sparc64 defconfig)
produced this warning:
mm/slab.c:808:13: warning: '__slab_error' defined but not used
[-Wunused-function]
On Tue, 18 Sep 2012, Dave Jones wrote:
It doesn't seem worth adding a new taint flag for this, so just re-use
the one from 'bad page'
Signed-off-by: Dave Jones da...@redhat.com
On Tue, Sep 18, 2012 at 11:19 PM, David Rientjes rient...@google.com wrote:
Acked-by: David Rientjes
On Tue, Sep 11, 2012 at 5:50 AM, Michael Wang
wrote:
> On 09/08/2012 04:39 PM, Pekka Enberg wrote:
>> On Fri, Sep 7, 2012 at 1:29 AM, Paul E. McKenney
>> wrote:
>>> On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
>>>> On 09/05/2012 09:55 PM, Chri
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/urgent
It has a PFMALLOC reserve page fixlet for slab from David Rientjes.
Pekka
-->
The following changes since commit
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/urgent
It has a PFMALLOC reserve page fixlet for slab from David Rientjes.
Pekka
--
The following changes since commit
On Tue, Sep 11, 2012 at 5:50 AM, Michael Wang
wang...@linux.vnet.ibm.com wrote:
On 09/08/2012 04:39 PM, Pekka Enberg wrote:
On Fri, Sep 7, 2012 at 1:29 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
On 09/05/2012 09:55 PM
Thanks.
To all three patches:
Acked-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Irina,
I commented on some of the patches but overall, I think the series makes sense:
Acked-by: Pekka Enberg
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On Sat, Sep 8, 2012 at 3:43 AM, Irina Tirdea wrote:
> From: Irina Tirdea
>
> perf uses the glibc version of basename(), by defining _GNU_SOURCE, including
> string.h and not including libgen.h. The glibc version of basename is better
> than the POSIX version since it does not modify its
On Sat, Sep 8, 2012 at 3:43 AM, Irina Tirdea wrote:
> From: Irina Tirdea
>
> __WORDSIZE is GLibC-specific and is not defined on all systems or glibc
> versions (e.g. Android's bionic does not define it).
>
> In file included from util/include/linux/bitmap.h:5:0,
> from
On Fri, Sep 7, 2012 at 1:29 AM, Paul E. McKenney
wrote:
> On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
>> On 09/05/2012 09:55 PM, Christoph Lameter wrote:
>> > On Wed, 5 Sep 2012, Michael Wang wrote:
>> >
>> >> Since the cachep and cachep->slabp_cache's l3 alien are in the same
these side effects with BUG_ON.
>
> For defining BUG_ON, use "if (cond) {}" insted of "if (cond) ;" because in
> the latter case build fails with "error: suggest braces around empty body in
> an ‘if’ statement [-Werror=empty-body]"
>
> Suggested
irina.tir...@intel.com
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Fri, Sep 7, 2012 at 1:29 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
On Thu, Sep 06, 2012 at 11:05:11AM +0800, Michael Wang wrote:
On 09/05/2012 09:55 PM, Christoph Lameter wrote:
On Wed, 5 Sep 2012, Michael Wang wrote:
Since the cachep and cachep-slabp_cache's l3 alien are
On Sat, Sep 8, 2012 at 3:43 AM, Irina Tirdea irina.tir...@gmail.com wrote:
From: Irina Tirdea irina.tir...@intel.com
__WORDSIZE is GLibC-specific and is not defined on all systems or glibc
versions (e.g. Android's bionic does not define it).
In file included from
On Sat, Sep 8, 2012 at 3:43 AM, Irina Tirdea irina.tir...@gmail.com wrote:
From: Irina Tirdea irina.tir...@intel.com
perf uses the glibc version of basename(), by defining _GNU_SOURCE, including
string.h and not including libgen.h. The glibc version of basename is better
than the POSIX
Hi Irina,
I commented on some of the patches but overall, I think the series makes sense:
Acked-by: Pekka Enberg penb...@kernel.org
Pekka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
.
To all three patches:
Acked-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
On Wed, Sep 5, 2012 at 1:02 AM, Pekka Enberg wrote:
> > How significant is the speed gain? The "isa_done" flag makes code flow
> > more difficult to follow.
On Wed, 5 Sep 2012, Yinghai Lu wrote:
> Not really much.
>
> when booting system:
> memmap=16m$128m memm
On Wed, Sep 5, 2012 at 1:02 AM, Pekka Enberg penb...@kernel.org wrote:
How significant is the speed gain? The isa_done flag makes code flow
more difficult to follow.
On Wed, 5 Sep 2012, Yinghai Lu wrote:
Not really much.
when booting system:
memmap=16m$128m memmap=16m$512m memmap=16m
On Wed, Sep 5, 2012 at 8:46 AM, Yinghai Lu wrote:
> They all need to go over ram range in same sequence. So add shared function
> to reduce duplicated code.
>
> -v2: Change to walk_ram_ranges() according to Pekka Enberg.
>
> Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
On Wed, Sep 5, 2012 at 8:46 AM, Yinghai Lu wrote:
> so could reduce one loop.
>
> Signed-off-by: Yinghai Lu
How significant is the speed gain? The "isa_done" flag makes code flow
more difficult to follow.
> ---
> arch/x86/mm/init.c | 21 ++---
> 1 files changed, 14
On Wed, Sep 5, 2012 at 8:46 AM, Yinghai Lu ying...@kernel.org wrote:
so could reduce one loop.
Signed-off-by: Yinghai Lu ying...@kernel.org
How significant is the speed gain? The isa_done flag makes code flow
more difficult to follow.
---
arch/x86/mm/init.c | 21 ++---
1
On Wed, Sep 5, 2012 at 8:46 AM, Yinghai Lu ying...@kernel.org wrote:
They all need to go over ram range in same sequence. So add shared function
to reduce duplicated code.
-v2: Change to walk_ram_ranges() according to Pekka Enberg.
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed
On Mon, Sep 3, 2012 at 9:17 AM, Yinghai Lu wrote:
> On Sun, Sep 2, 2012 at 10:50 PM, Pekka Enberg wrote:
>> On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
>>> This one intend to fix bugs:
>>> when efi booting have too many memmap entries, will need to doubl
On Mon, Sep 3, 2012 at 9:17 AM, Yinghai Lu ying...@kernel.org wrote:
On Sun, Sep 2, 2012 at 10:50 PM, Pekka Enberg penb...@kernel.org wrote:
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
This one intend to fix bugs:
when efi booting have too many memmap entries
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> This one intend to fix bugs:
> when efi booting have too many memmap entries, will need to double memblock
> memory array or reserved array.
Okay, why do we need to do that?
> +RESERVE_BRK(early_pgt_alloc, 65536);
What is this needed for?
>
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> +static void __init with_all_ram_ranges(
> + void (*work_fn)(unsigned long, unsigned long, void *),
> + void *data)
> +static void __init size_work_fn(unsigned long start, unsigned long end, void
>
t_all_memory_mapping to get right value
> -Yinghai Lu
>
> Signed-off-by: Jacob Shin
Yinghai's sign-off is missing.
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
e for_each_mem_pfn_range
> instead. - Yinghai Lu
> -v3: add calculate_all_table_space_size() to get correct needed page table
> size. - Yinghai Lu
>
> Signed-off-by: Jacob Shin
Yinghai's sign-off is missing.
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list:
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> From: Jacob Shin
>
> Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
> [ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
> pfn_mapped ranges instead.
What problem does this fix? How did you find about
org/lkml/2012/8/14/86
>
> Handle it by complaining, and adding the range back into the e820.
>
> Signed-off-by: Jacob Shin
This should have Yinghai's sign-off and the warning could be less cryptic.
As for the fix itself:
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send t
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> So later could make it call split_mem_range...
>
> Signed-off-by: Yinghai Lu
The commit title is utterly confusing. And it has a trailing dot (".").
As for the actual change:
Reviewed-by: Pekka Enberg
--
To unsubscribe f
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> it should take physical address range that will need to be mapped.
> and find_early_table_space should take range that pgt buff should be in.
> Separate those two to reduce confusion.
>
> Signed-off-by: Yinghai Lu
Reviewed-b
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> Should not do that in every calling of init_memory_mapping.
> Actually in early time, only need do once.
>
> Also move down early_memtest.
>
> Signed-off-by: Yinghai Lu
The changelog is too terse for my liking. I think it could use some
more
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> So we could put page table high again for 64bit.
>
> Signed-off-by: Yinghai Lu
The changelog for this is too terse for me to actually understand why
this is needed.
> ---
> arch/x86/mm/init.c |2 +-
> 1 files changed, 1 insertions(+), 1
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> from setup.c to mm/init.c
>
> So could update all related calling together later
>
> Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> from init_memory_mapping, so make init_memory_mapping readable.
>
> Suggested-by: Ingo Molnar
> Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> detect if need to use 1G or 2M and store them in page_size_mask.
>
> Only probe them one time.
>
> Suggested-by: Ingo Molnar
> Signed-off-by: Yinghai Lu
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send the
On Mon, Sep 3, 2012 at 4:45 AM, Namhyung Kim wrote:
> On Mon, 3 Sep 2012 03:04:32 +0300, Irina Tirdea wrote:
>> From: Irina Tirdea
>>
>> When NDEBUG is defined, the assert macro will be expanded to nothing.
>> Some assert calls used in perf are also including some functionality
>> (e.g. system
On Mon, Sep 3, 2012 at 4:45 AM, Namhyung Kim namhy...@kernel.org wrote:
On Mon, 3 Sep 2012 03:04:32 +0300, Irina Tirdea wrote:
From: Irina Tirdea irina.tir...@intel.com
When NDEBUG is defined, the assert macro will be expanded to nothing.
Some assert calls used in perf are also including some
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
detect if need to use 1G or 2M and store them in page_size_mask.
Only probe them one time.
Suggested-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
from init_memory_mapping, so make init_memory_mapping readable.
Suggested-by: Ingo Molnar mi...@elte.hu
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
from setup.c to mm/init.c
So could update all related calling together later
Signed-off-by: Yinghai Lu ying...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
So we could put page table high again for 64bit.
Signed-off-by: Yinghai Lu ying...@kernel.org
The changelog for this is too terse for me to actually understand why
this is needed.
---
arch/x86/mm/init.c |2 +-
1
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
Should not do that in every calling of init_memory_mapping.
Actually in early time, only need do once.
Also move down early_memtest.
Signed-off-by: Yinghai Lu ying...@kernel.org
The changelog is too terse for my liking. I
...@kernel.org
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
So later could make it call split_mem_range...
Signed-off-by: Yinghai Lu ying...@kernel.org
The commit title is utterly confusing. And it has a trailing dot (.).
As for the actual change:
Reviewed-by: Pekka Enberg penb
://lkml.org/lkml/2012/8/14/86
Handle it by complaining, and adding the range back into the e820.
Signed-off-by: Jacob Shin jacob.s...@amd.com
This should have Yinghai's sign-off and the warning could be less cryptic.
As for the fix itself:
Reviewed-by: Pekka Enberg penb...@kernel.org
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
From: Jacob Shin jacob.s...@amd.com
Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and
[ 4GB - max_pfn_mapped ) were always direct mapped, to now look up
pfn_mapped ranges instead.
What problem does
. - Yinghai Lu
-v3: add calculate_all_table_space_size() to get correct needed page table
size. - Yinghai Lu
Signed-off-by: Jacob Shin jacob.s...@amd.com
Yinghai's sign-off is missing.
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe
-Yinghai Lu
Signed-off-by: Jacob Shin jacob.s...@amd.com
Yinghai's sign-off is missing.
Reviewed-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
+static void __init with_all_ram_ranges(
+ void (*work_fn)(unsigned long, unsigned long, void *),
+ void *data)
+static void __init size_work_fn(unsigned long start, unsigned long
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu ying...@kernel.org wrote:
This one intend to fix bugs:
when efi booting have too many memmap entries, will need to double memblock
memory array or reserved array.
Okay, why do we need to do that?
+RESERVE_BRK(early_pgt_alloc, 65536);
What is this
__init intel_uncore_init(void)
>> if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
>> return -ENODEV;
>>
>> + if (cpu_has_hypervisor)
>> + return -ENODEV;
>> +
>> ret = uncore_pci_init();
>>
)
return -ENODEV;
+ if (cpu_has_hypervisor)
+ return -ENODEV;
+
ret = uncore_pci_init();
if (ret)
goto fail;
On Tue, Aug 21, 2012 at 3:55 PM, Pekka Enberg penb...@kernel.org wrote:
Tested-by: Pekka Enberg penb...@kernel.org
Ping
On Wed, Aug 29, 2012 at 2:41 PM, Haggai Eran wrote:
>> Looks like a problem in 072bb0aa5e0 ("mm: sl[au]b: add knowledge of
>> PFMEMALLOC reserve pages"). cache_grow() can reenable irqs which allows
>> this to be scheduled on a different cpu, possibly with a different node.
>> So it turns out
On Wed, Aug 29, 2012 at 2:41 PM, Haggai Eran hagg...@mellanox.com wrote:
Looks like a problem in 072bb0aa5e0 (mm: sl[au]b: add knowledge of
PFMEMALLOC reserve pages). cache_grow() can reenable irqs which allows
this to be scheduled on a different cpu, possibly with a different node.
So it
Dearest "wbrana",
On Sat, Aug 25, 2012 at 8:27 PM, wbrana wrote:
> Why did you send this irrelevant e-mail?
So despite my humble suggestion, you've filled up my inbox with
pointless rambling. Would it be at all possible you just got the f*ck
off LKML? I know it's difficult to hear this but
Dearest wbrana,
On Sat, Aug 25, 2012 at 8:27 PM, wbrana wbr...@gmail.com wrote:
Why did you send this irrelevant e-mail?
So despite my humble suggestion, you've filled up my inbox with
pointless rambling. Would it be at all possible you just got the f*ck
off LKML? I know it's difficult to hear
Hi Bernard,
(You didn't CC perf maintainers.)
On Thu, Aug 23, 2012 at 6:01 PM, Bernhard Rosenkraenzer
wrote:
> commit 4dc79eed16e3bb03b3cf92fcc6127e107e7537aa
> Author: Bernhard Rosenkraenzer
> Date: Sat Jun 23 06:18:05 2012 +0200
>
> perf: Port to Android
>
> Adapt perf to deal with
Dear "wbrana",
On Thu, Aug 23, 2012 at 9:17 PM, wbrana wrote:
> I'm user space developer. User space software also needs more time if
> more ABIs are supported.
I feel your pain.
As much as I appreciate your contribution here on LKML, I can't help
thinking that this discussion would be best
Dear wbrana,
On Thu, Aug 23, 2012 at 9:17 PM, wbrana wbr...@gmail.com wrote:
I'm user space developer. User space software also needs more time if
more ABIs are supported.
I feel your pain.
As much as I appreciate your contribution here on LKML, I can't help
thinking that this discussion
Hi Bernard,
(You didn't CC perf maintainers.)
On Thu, Aug 23, 2012 at 6:01 PM, Bernhard Rosenkraenzer
bernhard.rosenkran...@linaro.org wrote:
commit 4dc79eed16e3bb03b3cf92fcc6127e107e7537aa
Author: Bernhard Rosenkraenzer bernhard.rosenkran...@linaro.org
Date: Sat Jun 23 06:18:05 2012 +0200
On Tue, Aug 21, 2012 at 05:08:37PM +0800, Yan, Zheng wrote:
>> From: "Yan, Zheng"
>>
>> Initializing uncore PMU on virtualized CPU may hang the kernel.
>> This is because kvm does not emulate the entire hardware. Thers
>> are lots of uncore related MSRs, making kvm enumerate them all
>> is a
ta.x86_vendor != X86_VENDOR_INTEL)
> return -ENODEV;
>
> + if (cpu_has_hypervisor)
> + return -ENODEV;
> +
> ret = uncore_pci_init();
> if (ret)
> goto fail;
Tested-by: Pekka Enberg
--
To unsubscribe from this list: sen
)
return -ENODEV;
+ if (cpu_has_hypervisor)
+ return -ENODEV;
+
ret = uncore_pci_init();
if (ret)
goto fail;
Tested-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Tue, Aug 21, 2012 at 05:08:37PM +0800, Yan, Zheng wrote:
From: Yan, Zheng zheng.z@intel.com
Initializing uncore PMU on virtualized CPU may hang the kernel.
This is because kvm does not emulate the entire hardware. Thers
are lots of uncore related MSRs, making kvm enumerate them all
is
On Mon, Aug 20, 2012 at 4:59 AM, Namhyung Kim wrote:
> Forgot to add the #ifdefery to the below code also. :-/ Anyway, it needs
> to expose gtk specifics to general code with the #ifdef's. So I'd still
> prefer the original patch.
Fair enough.
Acked-by: Pekka Enberg
--
To unsubsc
On Sun, Aug 19, 2012 at 6:46 PM, David Ahern wrote:
> If GTK2 development packages are not installed, make is rather noisy:
[snip]
> Signed-off-by: David Ahern
> Cc: Arnaldo Carvalho de Melo
> Cc: Pekka Enberg
> Cc: Namhyung Kim
Acked-by: Pekka Enberg
--
To unsubscribe
On Sun, Aug 19, 2012 at 6:46 PM, David Ahern dsah...@gmail.com wrote:
If GTK2 development packages are not installed, make is rather noisy:
[snip]
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Cc: Pekka Enberg penb...@kernel.org
Cc
On Mon, Aug 20, 2012 at 4:59 AM, Namhyung Kim namhy...@kernel.org wrote:
Forgot to add the #ifdefery to the below code also. :-/ Anyway, it needs
to expose gtk specifics to general code with the #ifdef's. So I'd still
prefer the original patch.
Fair enough.
Acked-by: Pekka Enberg penb
_main_quit: assertion `main_loops !=
> NULL' failed
>
> Fix it by not to call it unnecessarily.
>
> Reported-by: Pekka Enberg
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/ui/gtk/setup.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/perf/ui/gtk/se
: assertion `main_loops !=
NULL' failed
Fix it by not to call it unnecessarily.
Reported-by: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
---
tools/perf/ui/gtk/setup.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/ui/gtk/setup.c b/tools
On Thu, 16 Aug 2012, Namhyung Kim wrote:
> Add helpline API implementation to GTK front-end.
For all three:
Acked-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hello,
I'm seeing this when I dock a Thinkpad X220 laptop:
[ 3129.616279] thinkpad_acpi: unknown possible thermal alarm or
keyboard event received
[ 3129.616297] thinkpad_acpi: unhandled HKEY event 0x6040
[ 3129.616298] thinkpad_acpi: please report the conditions when this
event happened to
Hello,
I'm seeing this when I dock a Thinkpad X220 laptop:
[ 3129.616279] thinkpad_acpi: unknown possible thermal alarm or
keyboard event received
[ 3129.616297] thinkpad_acpi: unhandled HKEY event 0x6040
[ 3129.616298] thinkpad_acpi: please report the conditions when this
event happened to
601 - 700 of 1778 matches
Mail list logo
