] page_fault
2.45%0.002572 sched-messaging [kernel.kallsyms] [k]
sock_alloc_send_pskb
I put the series on 'perf/time-sample-v1' branch in my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Any comments are welcome, thanks
Reviewed-by: Pekka Enberg penb
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
Cc: Ingo Molnar mi...@kernel.org
Signed-off-by: Pekka Enberg penb...@kernel.org
---
tools/perf/util/parse-events.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 9812531..c90e55c 100644
--- a/tools/perf
On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann jerry.hoem...@hp.com wrote:
Some platform have firmware that violates UEFI spec and access boot service
code or data segments after the system has called Exit Boot Services.
The call to efi_reserve_boot_services in setup_arch is a work around to
On 11/06/2013 05:33 PM, David Ahern wrote:
On 11/6/13, 4:47 AM, Ingo Molnar wrote:
I'm not too worried about call-graph 'legacies': it generates such huge
perf.data files which is parsed so slowly at the moment that there's
very
little user base ... Anyone who absolutely needs call-graph
Switch duration order to minimum, average, maximum for the '--summary'
command line option because it's more natural to read.
Cc: David Ahern dsah...@gmail.com
Cc: Ingo Molnar mi...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Signed-off-by: Pekka Enberg penb...@kernel.org
a...@ghostprotocols.net
Signed-off-by: Pekka Enberg penb...@kernel.org
---
tools/perf/builtin-trace.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index f841d2a..22354c8 100644
--- a/tools/perf
Ahern dsah...@gmail.com
Cc: Pekka Enberg penb...@kernel.org
Cc: Ingo Molnar mi...@kernel.org
Cc: Jiri Olsa jo...@redhat.com
Cc: Namhyung Kim namhy...@kernel.org
Cc: Adrian Hunter adrian.hun...@intel.com
---
Thanks David!
Tested-by: Pekka Enberg penb...@kernel.org
--
To unsubscribe from this list
Hi Jerry,
On Tue, Nov 12, 2013 at 7:55 PM, jerry.hoem...@hp.com wrote:
My change does not address platforms that have misbehaving firmware.
It just allows platforms that don't have this issue to avoid issues
that the call to efi_reserve_boot_services presents.
The problem I have with your
On 11/12/13 11:36 PM, David Ahern wrote:
On 11/12/13, 2:33 PM, Ingo Molnar wrote:
Summary of events:
dbus-daemon (555), 10 events, 0.0%, 0.000 msec
msec/call
syscallcalls min avg max stddev
--- --
On 11/12/13 11:40 PM, Ingo Molnar wrote:
So if you prefer unit-less lines that's defensible, perhaps output the
unit somewhere else:
syscallcalls min avg max stddev
(msec) (msec) (msec)(%)
---
...@redhat.com
Cc: Arnaldo Carvalho de Melo a...@ghostprotocols.net
Signed-off-by: Pekka Enberg penb...@kernel.org
---
tools/perf/builtin-trace.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 2a6149e
On Wed, Nov 13, 2013 at 2:57 PM, Ingo Molnar mi...@kernel.org wrote:
Are you convinced about double-digit precision output for percentages?
I think it suggest a false level of accuracy, but YYMV - typographically
xx.yy certainly looks nicer than xx.y (it's more symmetric).
Yeah, I think it's
Hi Jerry,
On Thu, Nov 14, 2013 at 1:57 AM, jerry.hoem...@hp.com wrote:
I will still point out that as currently used, efi_reserve_boot_services
is wrong. A work around for firmware bugs on one platform shouldn't be
breaking platforms that don't have that bug. Its just much less likely
to
Thread summary line coloring looks ugly. It doesn't add much value so
remove coloring completely.
Signed-off-by: Pekka Enberg penb...@kernel.org
---
tools/perf/builtin-trace.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/tools/perf/builtin-trace.c b/tools
On Thu, Nov 14, 2013 at 8:04 PM, jerry.hoem...@hp.com wrote:
Making this issue a quirk will be a lot more practical. Its a small, focused
change whose implications are limited and more easily understood.
There's nothing practical with requiring users to pass a kernel option
to make kdump
-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 11/15/13 2:50 AM, jerry.hoem...@hp.com wrote:
One already has to specify command line arguments to enable kdump.
Yes, so what?
The problem with your patch is that now to enable kdump, I have to know
that there's a second command line option and if my firmware is broken
or not. The
On 11/30/2013 01:42 PM, Meelis Roos wrote:
I am debugging a reboot problem on Sun Ultra 5 (sparc64) with 512M RAM
and turned on DEBUG_PAGEALLOC DEBUG_SLAB and DEBUG_SLAB_LEAK (and most
other debug options) and got the following BUG and hang on startup. This
happened originally with
On 12/03/2013 02:25 PM, Joonsoo Kim wrote:
No. He report that BUG() is triggered on v3.11-rc2 and v3.12.
And my recent change is merged into v3.13-rc1 as you know. :)
Hah, I guess my eyesight isn't what it used to be, I could have sworn it
said v3.13-rc2... Thanks anyway, Joonsoo!
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 jo...@redhat.com
Cc: Pekka Enberg penb
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 rient...@google.com
Acked-by: Pekka Enberg penb...@kernel.org
Andrew
On Sat, Jan 11, 2014 at 1:42 AM, Dave Hansen d...@sr71.net 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
Hi Paul,
On Sun, Feb 9, 2014 at 4:00 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com 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,
On Tue, Feb 11, 2014 at 2:14 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com 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
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter c...@linux.com 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:
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-linus
On Tue, May 7, 2013 at 5:23 PM, Christoph Lameter c...@linux.com 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
Hi Tony,
On Wed, May 8, 2013 at 8:16 AM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [130507 21:30]:
* Tony Lindgren t...@atomide.com [130507 17:35]:
* Pekka Enberg penb...@kernel.org [130506 23:42]:
Hi Linus,
Please pull the latest SLAB tree from
On Wed, May 8, 2013 at 2:58 PM, Glauber Costa glom...@parallels.com 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
Hello Sasha,
On Mon, Jun 10, 2013 at 10:18 PM, Sasha Levin sasha.le...@oracle.com wrote:
slab would still spew a warning when a big allocation happens with the
__GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
Hi Sasha,
On Tue, Jun 11, 2013 at 3:54 AM, Sasha Levin sasha.le...@oracle.com wrote:
On 06/10/2013 07:40 PM, Christoph Lameter wrote:
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [83ff4041] dump_stack+0x4e/0x82
[ 1691.812783]
On Tue, 11 Jun 2013, Sasha Levin wrote:
I think that leaving the warning makes sense to catch similar
things which are actually bugs - we had a similar issue with
/dev/kmsg (if I remember correctly) which actually pointed to
a bug.
On 6/11/13 6:14 PM, Christoph Lameter wrote:
Right.
Hello Kees,
On Tue, Jun 11, 2013 at 9:58 PM, Kees Cook keesc...@chromium.org wrote:
Moves the relocation handling into C, after decompression. This requires
that the decompressed size is passed to the decompression routine as
well so that relocations can be found. Only kernels that need
On Wed, Jun 12, 2013 at 7:26 PM, Kees Cook keesc...@chromium.org wrote:
On Tue, Jun 11, 2013 at 11:27 PM, Pekka Enberg penb...@kernel.org wrote:
Hello Kees,
On Tue, Jun 11, 2013 at 9:58 PM, Kees Cook keesc...@chromium.org wrote:
Moves the relocation handling into C, after decompression
On Wed, Jun 12, 2013 at 1:34 AM, Andrew Morton
a...@linux-foundation.org wrote:
__GFP_NOWARN is frequently used by kernel code to probe for how big an
allocation can I get. That's a bit lame, but it's used on slow paths
and is pretty simple.
Applied to slab/urgent, thanks guys!
--
To
On Mon, Apr 29, 2013 at 5:40 AM, Tetsuo Handa
penguin-ker...@i-love.sakura.ne.jp 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
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 KMALLOC_MAX_SIZE
On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter c...@linux.com 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
On Mon, May 6, 2013 at 9:59 AM, Geert Uytterhoeven ge...@linux-m68k.org wrote:
On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter c...@linux.com wrote:
Subject: slab: Return NULL for oversized allocations
The inline path seems to have changed the SLAB behavior for very large
kmalloc
On Tue, Jun 4, 2013 at 12:22 PM, Namhyung Kim namhy...@kernel.org wrote:
From: Namhyung Kim namhyung@lge.com
Display callchain information in the symbol column. It's only enabled
when recorded with -g and has symbol sort key.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung
On Tue, Jun 4, 2013 at 12:22 PM, Namhyung Kim namhy...@kernel.org wrote:
From: Namhyung Kim namhyung@lge.com
Display callchain percent value in the overhead column.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Reviewed-by: Pekka Enberg penb
for a tree view that has a lot
of rows.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@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
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 c...@linux.com
a reasonable
starting point. So FWIW,
Acked-by: Pekka Enberg penb...@kernel.org
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 unsubscribe
On Tue, Apr 23, 2013 at 5:31 PM, Aaron Tomlin atom...@redhat.com 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
Hello,
On Tue, Apr 23, 2013 at 12:16 AM, Andrew Morton
a...@linux-foundation.org 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
://lkml.kernel.org/r/1352753446-24109-1-git-send-email-sasha.le...@oracle.com
Signed-off-by: Ingo Molnar mi...@kernel.org
FWIW:
Acked-by: Pekka Enberg penb...@kernel.org
to the whole series.
Pekka
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
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 namhy...@kernel.org wrote:
From: Namhyung Kim namhyung@lge.com
Now an user can set a default value of --percent-limit option
On Thu, May 16, 2013 at 2:50 PM, Tang Chen tangc...@cn.fujitsu.com 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,
Hello,
On Tue, May 21, 2013 at 9:14 AM, Namhyung Kim namhy...@kernel.org 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,
On Tue, May 21, 2013 at 10:13 AM, Oskar Andero
oskar.and...@sonymobile.com 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 glom...@openvz.org
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
The GtkTreeStore can save items in a tree-like way. This is a
preparation for supporting callgraphs in the hist browser.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
Add a new column to display callchain information. It's only enabled
when recorded with -g and has symbol sort key.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
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 penb...@kernel.org
Signed-off-by: Namhyung Kim
On 05/22/2013 11:27 AM, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
If callchain is displayed, add row-activated signal handler for
handling double-click or pressing ENTER key action.
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
Reviewed
On 05/22/2013 11:37 AM, Namhyung Kim wrote:
From: Namhyung Kim namhyung@lge.com
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 penb...@kernel.org
Signed-off-by: Namhyung Kim namhy
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 namhy...@kernel.org wrote:
This patchset implements a new feature that collects hist entries in a
hierachical manner. That means lower
the external lkvm tree.
Signed-off-by: Borislav Petkov b...@suse.de
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
On 10/29/2013 11:55 AM, Hemant Kumar wrote:
1. Where this cache should be? Keeping it in tracing directory inside
the debugfs
directory should seem more feasible. And, shall this cache be shareable?
You can't share all of the cache because otherwise you'll expose details
on binaries that not
On Tue, Oct 29, 2013 at 4:51 PM, Mark Wielaard m...@redhat.com wrote:
A nice user case to think about when designing this interface might be
the java hotspot jvm (libjvm.so). It has SDT markers with the same name
that might occur at multiple addresses depending on code path taken or
compiler
On 10/30/2013 10:28 AM, Joonsoo Kim wrote:
If you want an incremental patch against original patchset,
I can do it. Please let me know what you want.
Yes, please. Incremental is much easier to deal with if we want this to
end up in v3.13.
Pekka
--
To unsubscribe from
On 10/30/13 12:05 PM, Masami Hiramatsu wrote:
To find all system libraries, we can use ldconfig.
$ ldconfig --print-cache
shows what dynamic libraries will be loaded. On my own laptop (running
ubuntu13.04) shows ~1000 libs.
Good point. That definitely narrows down the scanned set.
On Fri, Nov 1, 2013 at 9:55 AM, Ingo Molnar mi...@kernel.org wrote:
Btw., if anyone is interested in improving the GTK front-end, it
would be _really_ nice if it had a 'start profiling' button like
sysprof has today, with a 'samples' field showing the current number
of samples. (We could even
Hi Linus,
On Mon, Oct 14, 2013 at 10:57 PM, Linus Torvalds
torva...@linux-foundation.org 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
torva...@linux-foundation.org
On Wed, Oct 23, 2013 at 2:52 PM, Bobniev, Roman
roman.bobn...@sonymobile.com 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 c...@linux.com
Could you help me, who the maintainer
On Thu, Oct 24, 2013 at 9:58 AM, Ingo Molnar mi...@kernel.org 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.
Hello Hemant,
On Wed, Oct 23, 2013 at 7:05 AM, Hemant Kumar hks...@linux.vnet.ibm.com 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
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 a
On 10/26/2013 02:16 PM, Frank Ch. Eigler wrote:
Pekka Enberg penb...@kernel.org 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
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 see
Signed-off-by: Namhyung Kim namhy...@kernel.org
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
-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/
Hi Cody,
On Mon, May 13, 2013 at 10:08 PM, Cody P Schafer
c...@linux.vnet.ibm.com 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.
a...@firstfloor.org
Cc: Pekka Enberg penb...@kernel.org
Signed-off-by: Namhyung Kim namhy...@kernel.org
I'm not totally convinced this is useful. The limit is about what is
significant and that depends on what you are trying to measure.
There's an (absolute) lower limit somewhere between 0.1 and 1.0 but I
think
On Wed, May 15, 2013 at 8:10 PM, Zhouping Liu sanweiday...@gmail.com wrote:
From: Zhouping Liu z...@redhat.com
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 z...@redhat.com
On Sat, Aug 24, 2013 at 3:31 AM, Libin huawei.li...@huawei.com wrote:
Kmemcheck configuration menu location correction in Documentation/
kmemcheck.txt
Signed-off-by: Libin huawei.li...@huawei.com
Looks good to me. Andrew mind picking this up?
Acked-by: Pekka Enberg penb...@kernel.org
On Sat, Jul 6, 2013 at 3:09 AM, Simon Kirby s...@hostway.ca wrote:
We saw two Oopses overnight on two separate boxes that seem possibly
related, but both are weird. These boxes typically run btrfs for rsync
snapshot backups (and usually Oops in btrfs ;), but not this time!
backup02 was running
On 7/7/13 12:24 PM, Wanpeng Li wrote:
On Fri, Jul 05, 2013 at 01:37:28PM +, Christoph Lameter wrote:
On Thu, 4 Jul 2013, Wanpeng Li wrote:
This patch fix the callers that pass # of objects. Make sure they pass #
of slabs.
Acked-by: Christoph Lameter c...@linux.com
Hi Pekka,
Is it ok
On Wed, Jun 19, 2013 at 9:33 AM, Joonsoo Kim iamjoonsoo@lge.com wrote:
In free path, we don't check number of cpu_partial, so one slab can
be linked in cpu partial list even if cpu_partial is 0. To prevent this,
we should check number of cpu_partial in put_cpu_partial().
Signed-off-by:
not dereference beyond
kmalloc_caches[26] arrays.
Signed-off-by: Christoph Lameter c...@linux.com
Reported-by: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Pekka Enberg penb...@kernel.org
Cc: sta...@vger.kernel.org [3.10.x]
Signed-off-by: Andrew Morton a...@linux-foundation.org
On Mon, Jul 1, 2013 at 9:41 PM, Christoph Lameter c...@linux.com wrote:
On Tue, 25 Jun 2013, Michael Opdenacker wrote:
This patch is a proposed fix for this. It also removes the documentation
for kmalloc() in include/linux/slob_def.h which isn't included to
generate the documentation anyway.
On 2/5/13 4:58 PM, Christoph Lameter wrote:
On Tue, 5 Feb 2013, Steven Rostedt wrote:
Ping?
Obviously correct.
Acked-by: Christoph Lameter c...@linux.com
Applied, thanks a lot!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Mon, Jul 1, 2013 at 6:48 PM, Christoph Lameter c...@linux.com wrote:
On Mon, 24 Jun 2013, David Rientjes wrote:
On Mon, 24 Jun 2013, Wanpeng Li wrote:
This patch shares s_next and s_stop between slab and slub.
Just about the entire kernel includes slab.h, so I think you'll need to
On 07/08/2013 03:16 AM, Wanpeng Li wrote:
On Sun, Jul 07, 2013 at 07:41:54PM +0300, Pekka Enberg wrote:
On Mon, Jul 1, 2013 at 6:48 PM, Christoph Lameter c...@linux.com wrote:
On Mon, 24 Jun 2013, David Rientjes wrote:
On Mon, 24 Jun 2013, Wanpeng Li wrote:
This patch shares s_next
On Fri, Jul 19, 2013 at 6:13 PM, Alexandru Juncu al...@rosedu.org 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
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://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 c...@linux.com 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
, feste...@gmail.com, Fabio Estevam
fabio.este...@freescale.com,Christoph Lameter c...@linux.com, David Rientjes
rient...@google.com, Pekka Enberg penb...@kernel.org
Subject: [PATCH] mm: slub: Place count_partial() outside CONFIG_SLUB_DEBUG if
block
On Mon, 12 May 2014, Jim Davis wrote
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
tree.
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://www.tux.org/lkml/
701 - 800 of 1778 matches
Mail list logo
