On Mon, May 13, 2013 at 11:41 AM, Namhyung Kim wrote:
> From: Namhyung Kim
>
> The --percent-limit option is for not showing small overheaded entries
> in the output. Maybe we want to set a certain default value like 0.1.
>
> Cc: Andi Kleen
> Signed-off-by: Namhyung
On Mon, May 13, 2013 at 11:41 AM, Namhyung Kim wrote:
> From: Namhyung Kim
>
> The --percent-limit option is for not showing small overheaded entries
> in the output.
>
> Cc: Andi Kleen
> Signed-off-by: Namhyung Kim
Acked-by: Pekka Enberg
--
To unsubscribe from thi
Hi Cody,
On Mon, May 13, 2013 at 10:08 PM, Cody P Schafer
wrote:
> "Problems" with the current code:
> 1. there is a lack of synchronization in setting ->high and ->batch in
> percpu_pagelist_fraction_sysctl_handler()
> 2. stop_machine() in zone_pcp_update() is unnecissary.
> 3.
On Tue, May 14, 2013 at 5:09 AM, Namhyung Kim wrote:
> From: Namhyung Kim
>
> Now an user can set a default value of --percent-limit option into the
> perfconfig file.
>
> $ cat ~/.perfconfig
> [report]
> percent-limit = 0.1
>
> Cc: Andi Kleen
> Cc: Pekka
On Wed, May 15, 2013 at 8:10 PM, Zhouping Liu wrote:
> From: Zhouping Liu
>
> commit 48356303ff(mm, slab: Rename __cache_alloc() -> slab_alloc())
> forgot to update the comment 'kmem_cache_alloc' to 'slab_alloc_node'.
>
> Signed-off-by: Zhouping Liu
> ---
> mm/slab.c | 2 +-
> 1 file changed,
-git-send-email-sasha.le...@oracle.com
Signed-off-by: Ingo Molnar
FWIW:
Acked-by: Pekka Enberg
to the whole series.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On 05/15/2013 01:08 PM, Namhyung Kim wrote:
Hi Pekka,
On Tue, 14 May 2013 14:05:38 +0300, Pekka Enberg wrote:
On Tue, May 14, 2013 at 5:09 AM, Namhyung Kim wrote:
From: Namhyung Kim
Now an user can set a default value of --percent-limit option into the
perfconfig file.
$ cat
Applied all patches, thanks a lot Michael!
--
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 Mon, Feb 4, 2013 at 9:13 PM, Ingo Molnar wrote:
>
> * Greg Kroah-Hartman wrote:
>
>> On Mon, Feb 04, 2013 at 10:57:35AM -0800, David Rientjes wrote:
>> > On Mon, 4 Feb 2013, Ingo Molnar wrote:
>> >
>> > > > arch/x86/Kconfig | 1 +
>> > > > 1 file changed, 1 insertion(+)
>> > > >
>> > > >
On Wed, Feb 6, 2013 at 11:44 AM, James Hogan wrote:
> On 05/02/13 18:34, Christoph Lameter wrote:
>> On Tue, 5 Feb 2013, James Hogan wrote:
>>
>>> On 05/02/13 16:36, Christoph Lameter wrote:
OK I was able to reproduce it by setting ARCH_DMA_MINALIGN in slab.h. This
patch fixes it here:
On Wed, Feb 6, 2013 at 10:12 PM, David Rientjes wrote:
> What's the endgame for kvmtool/next? The patch that this fixes has been
> sitting in linux-next for over 15 months and hasn't been pulled by Linus,
> yet some find it to be quite useful.
>
> Is it a permanent addition to linux-next, is
On Thu, Feb 7, 2013 at 12:11 AM, Sasha Levin wrote:
> This patch series adds in LD_PRELOAD support for liblockdep.
FWIW,
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 m
ntation, the last one is
> an example of liblock being used on an existing codebase.
This is awesome, Sasha! For the whole series:
Acked-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
s and they look like a reasonable
starting point. So FWIW,
Acked-by: Pekka Enberg
Are there any plans in trying to consolidate 'perf trace' and this? As
a user I don't really care what the underlying mechanism and would
like things to just work out of the box.
Pekka
--
To
On 4/30/13 5:34 PM, Christoph Lameter wrote:
On Tue, 30 Apr 2013, Tetsuo Handa wrote:
Current diff is:
[off by one stuff okay]
diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h
index 113ec08..be1446a 100644
--- a/include/linux/slab_def.h
+++ b/include/linux/slab_def.h
@@
On 4/30/13 8:27 PM, Christoph Lameter wrote:
"kmalloc() returning NULL for these allocations" is needed by "try kmalloc()
first, fallback to vmalloc()" allocation. There are kernel modules which expect
kmalloc() to return NULL rather than oops when the requested size is larger
than
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote:
> Enabling various debugging options increases the size of structures and
> the subslab handling in SLABs kmem_cache_create will start to fail.
>
>
> Here is a fix for that:
>
> Subject: Fix bootstrap creation of kmalloc caches
>
> For SLAB
On Mon, May 6, 2013 at 9:59 AM, Geert Uytterhoeven wrote:
> On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter wrote:
>> Subject: slab: Return NULL for oversized allocations
>>
>> The inline path seems to have changed the SLAB behavior for very large
>> kmalloc allocations. This patch restores
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote:
> - for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++)
This didn't match what I had in my tree. I fixed it by hand but please
verify the end result:
tly bootstrap boot caches
Joonsoo Kim (3):
mm/sl[au]b: correct allocation type check in kmalloc_slab()
slub: correct to calculate num of acquired objects in get_partial_node()
slub: add 'likely' macro to inc_slabs_node()
Pekka Enberg (1):
Merge branch 'slab/next' into slab/for-li
On Tue, May 7, 2013 at 5:23 PM, Christoph Lameter wrote:
> Well this is because you did not take the patch that changed the way
> KMALLOC_SHIFT_HIGH is treated.
Is that still needed? I only took the ones Tetsuo said were needed to
fix the issue at hand.
Pekka
--
To
Hi Tony,
On Wed, May 8, 2013 at 8:16 AM, Tony Lindgren wrote:
> * Tony Lindgren [130507 21:30]:
>> * Tony Lindgren [130507 17:35]:
>> > * Pekka Enberg [130506 23:42]:
>> > > Hi Linus,
>> > >
>> > > Please pull the latest SLAB tree fr
On Wed, May 8, 2013 at 2:58 PM, Glauber Costa wrote:
> My first guess is that it hit a NULL cache. Being a NULL pointer
> dereference, the thing among all that has the biggest chances of being
> NULL and accessed unconditionally is the cache pointer itself.
>
> Due to the size being too big. But
On Fri, Feb 22, 2013 at 7:23 PM, Christoph Lameter wrote:
> On Fri, 22 Feb 2013, Glauber Costa wrote:
>
>> On 02/22/2013 09:01 PM, Christoph Lameter wrote:
>> > Argh. This one was the final version:
>> >
>> > https://patchwork.kernel.org/patch/2009521/
>> >
>>
>> It seems it would work. It is all
tly
slab: Fixup CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections
Glauber Costa (1):
slub: correctly bootstrap boot caches
Joonsoo Kim (1):
mm/sl[au]b: correct allocation type check in kmalloc_slab()
Pekka Enberg (1):
Merge branch 'slab/next' into slab/for-linus
fs/proc/sta
Hello,
On 04/11/2013 07:42 PM, Christoph Lameter wrote:
On Thu, 11 Apr 2013, Steven Rostedt wrote:
I was wondering if you made any more forward progress with with patch
yet. When it goes into mainline, I'd like to backport it to the -rt
stable trees, and will probably make it enabled by
Hello,
On 4/12/13 9:19 PM, Borislav Petkov wrote:
so I'm currently experimenting with my randconfig build scripts and
thought that maybe it would be a cool thing to not only do the random
builds only but also boot-test them in kvm. Which reminded me that we
have that KVMTOOL_TEST_ENABLE config
Hello,
I'm seeing this when I try to build perf in v3.9-rc7:
[penberg@golgotha perf]$ make
CHK -fstack-protector-all
CHK -Wstack-protector
CHK -Wvolatile-register-var
CHK -D_FORTIFY_SOURCE=2
CHK bionic
CHK libelf
CHK libdw
Makefile:584: No libdw.h found or old libdw.h
Hello,
On Tue, Apr 16, 2013 at 5:14 AM, Namhyung Kim wrote:
>> The problem is that I didn't have python-devel package installed and
>> get-executable-or-default decides to error out instead of letting the
>> Makefile disable Python support.
>
> Right. I think the get-executable-or-default
dn't fully agreed
>> with
>> your patch and recommended to revert original commit yesterday. After
>> reverting
>> that, I would attempt to remove the callsites.
>>
>> But, now, I change my thought, because of your explanation. There are
>> already
>&
On Thu, Jan 9, 2014 at 2:19 AM, Andrew Morton wrote:
>> cache-misses are reduced by this patchset, roughly 5%.
>> And elapsed times are also improved by 3.1% to baseline.
>
> ah, OK, thanks, useful. A few instructions added to page_mapping()
> won't have effects like that!
Yup, I merged the
On 03/03/2014 03:14 AM, Namhyung Kim wrote:
The __hpp__color_fmt used in the gtk code can be replace by the
generic code with small change in print_fn callback.
This is a preparation to upcoming changes and no functional changes
intended.
Cc: Jiri Olsa
Cc: Pekka Enberg
Signed-off
On 02/20/2014 12:14 AM, David Rientjes wrote:
Kmemcheck should use the preferred interface for parsing command line
arguments, kstrto*(), rather than sscanf() itself. Use it appropriately.
Signed-off-by: David Rientjes
Acked-by: Pekka Enberg
Andrew, can you pick this up?
---
arch/x86
On Fri, Dec 13, 2013 at 9:03 AM, Joonsoo Kim wrote:
> Hello, Pekka.
>
> Below is updated patch for 5/5 in this series.
> Now I get acks from Christoph to all patches in this series.
> So, could you merge this patchset? :)
> If you want to resend wholeset with proper ack, I will do it
> with
Hi Paul,
On 01/02/2014 10:33 PM, Paul E. McKenney wrote:
From what I can see, the Linux-kernel's SLAB, SLOB, and SLUB memory
allocators would deal with the following sort of race:
A. CPU 0: r1 = kmalloc(...); ACCESS_ONCE(gp) = r1;
CPU 1: r2 = ACCESS_ONCE(gp); if (r2) kfree(r2);
Hi Paul,
On Sun, Feb 9, 2014 at 4:00 AM, Paul E. McKenney
wrote:
> From what I can see, (A) works by accident, but is kind of useless because
> you allocate and free the memory without touching it. (B) and (C) are the
> lightest touches I could imagine, and as you say, both are bad. So I
>
On Tue, Feb 11, 2014 at 2:14 PM, Paul E. McKenney
wrote:
> In contrast, from kfree() to a kmalloc() returning some of the kfree()ed
> memory, I believe the kfree()/kmalloc() implementation must do any needed
> synchronization and ordering. But that is a different set of examples,
> for example,
On Sat, Oct 5, 2013 at 10:48 AM, Wanpeng Li wrote:
> On Tue, Sep 10, 2013 at 11:43:37AM +0800, Li Zefan wrote:
>> /sys/kernel/slab/:t-048 # cat cpu_slabs
>> 231 N0=16 N1=215
>> /sys/kernel/slab/:t-048 # cat slabs
>> 145 N0=36 N1=109
>>
>>See, the number of slabs is smaller than that
On Sat, Dec 28, 2013 at 3:50 AM, Li Zefan wrote:
> On 2013/12/27 17:46, Wanpeng Li wrote:
>> SLUB per cpu partial cache is a list of slab caches to accelerate objects
>> allocation. However, current codes just accumulate the objects number of
>> the first slab cache of per cpu partial cache
On 12/30/2013 03:08 AM, Wanpeng Li wrote:
Zefan's patch is good enough, mine doesn't need any more.
OK, thanks guys!
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 info at
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/next
Nothing terribly exciting here apart from Christoph's kmalloc
unification patches that brings sl[aou]b implementations closer to
each other.
Pekka
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 regression fix for overly eager slab cache name checks.
Pekka
-->
The following changes since commit
Hi Linus,
On Mon, Oct 14, 2013 at 10:57 PM, Linus Torvalds
wrote:
> [ Adding Pekka to verify the SLAB_DESTROY_BY_RCU semantics, and Peter
> Hurley due to the possible tty association ]
>
> On Mon, Oct 14, 2013 at 10:31 AM, Linus Torvalds
> wrote:
>>
>> Oleg, does this trigger any memory for
On Wed, Oct 23, 2013 at 2:52 PM, Bobniev, Roman
wrote:
>> On Tue, 8 Oct 2013, Tim Bird wrote:
>>
>> > It also fixes a bug where kmemleak was only partially enabled in some
>> > configurations.
>>
>> Acked-by: Christoph Lameter
>
> Could you help me, who the maintainer is that
> puts this patch
On Thu, Oct 24, 2013 at 9:58 AM, Ingo Molnar wrote:
> - In a similar fashion, it would be nice to see it integrated with
>'perf probe' or 'perf ktap', so that users can create probes from
>a single place, with coherent syntax and integrated analysis
>capabilities. I.e. there's no
Hello Hemant,
On Wed, Oct 23, 2013 at 7:05 AM, Hemant Kumar wrote:
> This allows perf to probe into the sdt markers/notes present in
> the libraries and executables. We try to find the associated location
> and handle prelinking (since, stapsdt notes section is not allocated
> during runtime).
> Technically feasible. But then we would have to parse each of the
> libraries and executables to list them. Right? I am not sure if such a
> delay is acceptable.
You could do it at 'perf list' time or even build time and cache it. And add
lazy discovery to 'perf record' and friends.
> Also if
On 10/26/2013 02:16 PM, Frank Ch. Eigler wrote:
Pekka Enberg writes:
Is there a technical reason why 'perf list' could not show all the
available SDT markers on a system and that the 'mark to event'
mapping cannot happen automatically? [...]
A quick experiment with:
find `echo $PATH | tr
Hi David,
On 10/25/2013 06:20 PM, David Ahern wrote:
On 10/25/13 8:20 AM, Pekka Enberg wrote:
Technically feasible. But then we would have to parse each of the
libraries and executables to list them. Right? I am not sure if such a
delay is acceptable.
You could do it at 'perf list' time
On 10/26/2013 12:50 PM, Ingo Molnar wrote:
I think in 99% of the usecases people will either use pre-built
markers that come with their distro, or will be intimately aware of
the markers because they are in the very app they are developing.
So I wouldn't worry about 'user has a weird binary'
On 10/28/13 1:23 PM, Masami Hiramatsu wrote:
By the way, what happens if multiple binaries has same SDT marker?
Yeah, perf list shows just one and ignores others. However, if we
probe one, and run binary which use the other one, user will never
see the marker.
So, it still needs a concrete
On 10/28/2013 04:11 PM, Srikar Dronamraju wrote:
But what if a system has both 32 bit libc and 64 bit libc?
Wont we could end up with 2 libc:setjmp?
Should we give some more intelligence into perf to choose the 64 bit
libc over 32 bit one?
You can just trace both of them by default, no?
On 10/28/13 7:31 PM, Srikar Dronamraju wrote:
But what if a system has both 32 bit libc and 64 bit libc?
Wont we could end up with 2 libc:setjmp?
Should we give some more intelligence into perf to choose the 64 bit
libc over 32 bit one?
You can just trace both of them by default, no?
There
On 10/28/13 6:59 PM, David Ahern wrote:
> I often use perf-list to lookup an exact event name, and I do not want
> to see it taking many seconds to minutes to run (not everyone is
> running on an SSD). I also run perf on many different OS versions with
> an NFS home directory, and do not want to
On Sat, Aug 24, 2013 at 3:31 AM, Libin wrote:
> Kmemcheck configuration menu location correction in Documentation/
> kmemcheck.txt
>
> Signed-off-by: Libin
Looks good to me. Andrew mind picking this up?
Acked-by: Pekka Enberg
--
To unsubscribe from this list: send the line "
On Fri, Jul 19, 2013 at 5:45 PM, Alexandru Juncu wrote:
> Found using coccinelle. It suggested kmalloc/strcpy should be replaced
> with kstrdup, but the entire function can be replaced by kstrdup.
>
> Signed-off-by: Alexandru Juncu
> ---
> drivers/staging/lustre/lustre/libcfs/libcfs_string.c |
On Fri, Jul 19, 2013 at 6:13 PM, Alexandru Juncu wrote:
> I was thinking the same thing, but I hesitated because I didn't know
> how used it was and I didn't want to break something.
"git grep cfs_strdup" suggests that nobody uses it so you could just
remove it completely...
--
To unsubscribe
Hi Christoph,
On Wed, Mar 6, 2013 at 6:38 PM, Christoph Lameter wrote:
> Well this stuff was already ready for 3.8 and missed that merge period as
> well. There are a couple of bug fixes included as well. It is the basis
> for more common code between allocators. Most of it is renaming things so
On Sun, Mar 10, 2013 at 8:44 AM, Yinghai Lu wrote:
> +void __init x86_acpi_override_find(void)
> +{
> + unsigned long ramdisk_image, ramdisk_size;
> + unsigned char *p = NULL;
> +
> +#ifdef CONFIG_X86_32
> + struct boot_params *boot_params_p;
> +
> + /*
> +* 32bit
On Sun, Mar 10, 2013 at 10:01 AM, Jiang Liu wrote:
> Use helper function free_highmem_page() to free highmem pages into
> the buddy system.
>
> Signed-off-by: Jiang Liu
> ---
> arch/x86/mm/highmem_32.c |1 -
> arch/x86/mm/init_32.c| 10 +-
> 2 files changed, 1 insertion(+), 10
On Sun, Mar 10, 2013 at 12:32 PM, Pekka Enberg wrote:
> On Sun, Mar 10, 2013 at 10:01 AM, Jiang Liu wrote:
>> Use helper function free_highmem_page() to free highmem pages into
>> the buddy system.
>>
>> Signed-off-by: Jiang Liu
>> ---
>> arch/x86/m
On Sun, Mar 10, 2013 at 10:01 AM, Jiang Liu wrote:
> Introduce helper function free_highmem_page(), which will be used by
> architectures with HIGHMEM enabled to free highmem pages into the buddy
> system.
>
> Signed-off-by: Jiang Liu
Reviewed-by: Pekka Enberg
--
To unsubscribe
On Sun, Mar 10, 2013 at 3:06 PM, Alex Grad wrote:
> Signed-off-by: Alex Grad
> ---
> arch/powerpc/kernel/kgdb.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 5ca82cd..c1eef24 100644
> ---
On Sun, Mar 10, 2013 at 2:48 PM, Mihnea Dobrescu-Balaur
wrote:
> Signed-off-by: Mihnea Dobrescu-Balaur
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 majordomo
On Sun, Mar 10, 2013 at 3:13 PM, Stelian Nirlu wrote:
> Signed-off-by: Stelian Nirlu
> ---
> arch/s390/net/bpf_jit_comp.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
> index 0972e91..e645528 100644
>
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/urgent
It contains a slab regression fix by Sasha Levin.
Pekka
-->
The following changes since commit
On Mon, 27 May 2013, Peter Zijlstra wrote:
>> Before your patch pinned was included in locked and thus RLIMIT_MEMLOCK
>> had a single resource counter. After your patch RLIMIT_MEMLOCK is
>> applied separately to both -- more or less.
On Tue, May 28, 2013 at 7:37 PM, Christoph Lameter wrote:
>
On Tue, Jun 4, 2013 at 12:22 PM, Namhyung Kim wrote:
> From: Namhyung Kim
>
> Display callchain information in the symbol column. It's only enabled
> when recorded with -g and has symbol sort key.
>
> Cc: Pekka Enberg
> Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enbe
On Tue, Jun 4, 2013 at 12:22 PM, Namhyung Kim wrote:
> From: Namhyung Kim
>
> Display callchain percent value in the overhead column.
>
> Cc: Pekka Enberg
> Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send the line "u
that has a lot
> of rows.
>
> Cc: Pekka Enberg
> Signed-off-by: Namhyung Kim
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 majordomo info at http://vger.kerne
On Thu, May 16, 2013 at 2:50 PM, Tang Chen wrote:
> The following patch-set allocated pagetables to local node.
> https://lkml.org/lkml/2013/4/11/829
>
> Doing this will break memory hot-remove.
>
> Before removing memory, the kernel offlines memory. If offlining
> memory fails, the memory cannot
Hello,
On Tue, May 21, 2013 at 9:14 AM, Namhyung Kim wrote:
> This patchset implements a new feature that collects hist entries in a
> hierachical manner. That means lower-level entries are belonged to an
> upper-level entry. The entry hierachy is built on the sort keys
> given, so users can
On Tue, May 21, 2013 at 10:13 AM, Oskar Andero
wrote:
> Add a VM_BUG_ON to catch any illegal value from the shrinkers. It's a
> potential bug if scan_objects returns a negative other than -1 and
> would lead to undefined behaviour.
>
> Cc: Glauber Costa
> Cc: Dave Chinner
> Cc: Andrew Morton
>
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim
The GtkTreeStore can save items in a tree-like way. This is a
preparation for supporting callgraphs in the hist browser.
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enberg
--
To unsubscribe from
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim
Add a new column to display callchain information. It's only enabled
when recorded with -g and has symbol sort key.
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim
Add a new column for showing callchain overhead. I feel like it's
more natural than having those overhead next to a first child in a
same column.
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enberg
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim
If callchain is displayed, add "row-activated" signal handler for
handling double-click or pressing ENTER key action.
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enberg
--
To unsubscribe from
On 05/22/2013 11:37 AM, Namhyung Kim wrote:
From: Namhyung Kim
Sometimes it's annoying to see when some symbols have very wierd long
names. So it might be a good idea to make column size changable.
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
Reviewed-by: Pekka Enberg
--
To unsubscribe
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
This patchset implements callchain support in GTK report browser as
Pekka requested. I put callchain overhead on its own column because
it looks more natural to me. Please take a look and give me comments.
You can get it from 'perf/callchain-gtk-v1'
On 05/21/2013 10:26 AM, Namhyung Kim wrote:
On Tue, 21 May 2013 10:04:05 +0300, Pekka Enberg wrote:
Hello,
On Tue, May 21, 2013 at 9:14 AM, Namhyung Kim wrote:
This patchset implements a new feature that collects hist entries in a
hierachical manner. That means lower-level entries
the external lkvm tree.
Signed-off-by: Borislav Petkov
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 re
On Tue, Apr 23, 2013 at 5:31 PM, Aaron Tomlin wrote:
> This patch is in response to BZ#42967 [1].
> Using VM_BUG_ON so it's used only when CONFIG_DEBUG_VM is set,
> given that cache_alloc_node() is a hot code path.
The patch is pretty badly mangled and does not apply with 'git am'.
Please
Hello,
On Tue, Apr 23, 2013 at 12:16 AM, Andrew Morton
wrote:
> The patch made index_of() weaker!
>
> It's probably all a bit academic, given that linux-next does
>
> -/*
> - * This function must be completely optimized away if a constant is passed to
> - * it. Mostly the same as what is in
On Mon, Apr 29, 2013 at 5:40 AM, Tetsuo Handa
wrote:
> Tetsuo Handa wrote:
>> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26.
>>
>> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and
>> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case
>> happens),
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen wrote:
> On 01/10/2014 03:39 PM, Andrew Morton wrote:
>>> I tested 4 cases, all of these on the "cache-cold kfree()" case. The
>>> first 3 are with vanilla upstream kernel source. The 4th is patched
>>> with my new slub code (all single-threaded):
On 01/10/2014 02:23 PM, Peter Zijlstra wrote:
Instead of using comments in an attempt at getting the locking right,
use proper assertions that actively warn you if you got it wrong.
Also add extra braces in a few sites to comply with coding-style.
Signed-off-by: Peter Zijlstra
Applied,
On 12/17/2013 02:45 AM, Dave Hansen wrote:
I'll do some testing and see if I can coax out any delta from the
optimization myself. Christoph went to a lot of trouble to put this
together, so I assumed that he had a really good reason, although the
changelogs don't really mention any.
IIRC it's
On 12/18/2013 03:16 PM, Vladimir Davydov wrote:
Signed-off-by: Vladimir Davydov
Cc: Michal Hocko
Cc: Johannes Weiner
Cc: Glauber Costa
Cc: Christoph Lameter
Cc: Pekka Enberg
Cc: Andrew Morton
Look good to me. Even though this patch just touches slab, I think it
should go through
On 12/19/2013 11:26 AM, Vasily Averin wrote:
On 12/19/2013 12:39 PM, Vladimir Davydov wrote:
On 12/19/2013 12:17 PM, Vasily Averin wrote:
On 12/18/2013 05:16 PM, Vladimir Davydov wrote:
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -176,8 +176,9 @@ kmem_cache_create_memcg(struct mem_cgroup
On 01/24/2014 04:21 PM, Peter Zijlstra wrote:
Dave Hansen already send a fix for that:
lkml.kernel.org/r/52d5746f.2040...@intel.com
Pekka, any chance to get that merged?
Sorry for the delay - I'm way behind my inbox.
It's applied now, thanks!
Pekka
--
To unsubscribe
On 01/16/2014 03:49 AM, Namhyung Kim wrote:
Gaurav reported that perf cannot profile JIT program if it executes
the code on heap. This was because current map__new() only handle JIT
on anon mappings - extends it to handle no_dso (heap, stack) case too.
This patch assumes JIT profiling only
On 01/31/2014 05:04 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Jan 31, 2014 at 01:50:27PM +0200, Pekka Enberg escreveu:
On 01/16/2014 03:49 AM, Namhyung Kim wrote:
Gaurav reported that perf cannot profile JIT program if it executes
the code on heap. This was because current map__new() only
Hi Linus,
Please pull the latest SLAB tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/penberg/linux.git slab/next
It contains random bug fixes that have accumulated in my inbox over
the past few months.
Pekka
-->
The following changes since
On Tue, May 6, 2014 at 6:32 AM, Linus Torvalds
wrote:
> On Mon, May 5, 2014 at 8:25 PM, David Miller wrote:
>>
>>> Sam Ravnborg wrote:
There is a related patch in this area which I think is not yet applied.
See: https://lkml.org/lkml/2014/4/18/28
Maybe this is
-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/
On 05/23/2014 11:16 PM, Mike Snitzer wrote:
On Tue, Mar 25 2014 at 2:07pm -0400,
Christoph Lameter wrote:
On Tue, 25 Mar 2014, Mike Snitzer wrote:
This patch still isn't upstream. Who should be shepherding it to Linus?
Pekka usually does that.
Acked-by: Christoph Lameter
This still
Estevam
,Christoph Lameter , David Rientjes
, Pekka Enberg
Subject: [PATCH] mm: slub: Place count_partial() outside CONFIG_SLUB_DEBUG if
block
On Mon, 12 May 2014, Jim Davis wrote:
Building with the attached random configuration file,
mm/slub.c: In function ‘show_slab_objects’:
mm/slub.c
ORK_CPU_UNBOUND work on
wq_unbound_cpumask CPUs")
CC:
Cc: Joonsoo Kim
Cc: David Rientjes
Cc: Pekka Enberg
Cc: Christoph Lameter
Cc: Tejun Heo
Cc: Lai Jiangshan
Cc: John Stultz
Cc: Thomas Gleixner
Cc: Stephen Boyd
Acked-by: Pekka Enberg
---
mm/slab.c | 3 ++-
1 file changed
On Tue, Aug 11, 2020 at 5:25 AM wrote:
>
> From: Abel Wu
>
> The ALLOC_SLOWPATH statistics is missing in bulk allocation now.
> Fix it by doing statistics in alloc slow path.
>
> Signed-off-by: Abel Wu
Reviewed-by: Pekka Enberg
On Wed, Aug 26, 2020 at 5:54 PM Nicholas Piggin wrote:
>
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Acked-by: Palmer Dabbelt
> Signed-off-by: Nicholas Piggin
Reviewed-by: Pekka Enberg
1301 - 1400 of 1778 matches
Mail list logo
