ist
> for quite a while, which indicates there are no or less users. Users
> (if any) should switch to oprofile 1.x or the perf tool. No need to
> carry kernel support any longer with us.
>
> So time to get rid of it. For the whole series:
>
> Acked-by: Robert Richter
"oprofile" program doesn't actually use the
> legacy kernel code any more, and hasn't for a long time.
>
> But I might be wrong. Adding William Cohen to the cc, since he seems
> to still maintain it to make sure it builds etc.
>
> Linus
>
Hi,
Yes
l it would be interesting to look at the two raw values used to compute the
delta to better diagnose what is going on.
-Will
>
> -Original Message-
> From: William Cohen [mailto:wco...@redhat.com]
> Sent: 2019年4月12日 22:06
> To: Linhaifeng ; linux-perf-us...@vger.kernel.or
On 4/11/19 8:57 PM, Linhaifeng wrote:
> Hi,
> I have a single thread application like this:
>
> While (1) {
> start = rdtsc();
> sqrt (1024);
> end = rdtsc();
> cycles = end – start;
> printf("cycles: %d-%02d-%02d %02d:%02d:%02d: %lu\n",
> 1900+timeinfo->tm_year, 1+time
similar to the ARM64 export of
save_stack_trace_tsk() added in git commit e27c7fa015d6.
Signed-off-by: William Cohen
---
arch/arm64/kernel/stacktrace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
index 1a29f2695ff2..d908b5e9e949
Commit-ID: 2d08f87fe7a2e4d74dc8b0eb645737d83dd932a9
Gitweb: https://git.kernel.org/tip/2d08f87fe7a2e4d74dc8b0eb645737d83dd932a9
Author: William Cohen
AuthorDate: Tue, 29 Jan 2019 12:05:36 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 6 Feb 2019 10:00:40 -0300
perf vendor
Fix incorrect event names for the Load_Miss_Real_Latency metric for
Cascadelake server in the same manner as commit 91b2b97025 for SKL/SKX.
Signed-off-by: William Cohen
---
tools/perf/pmu-events/arch/x86/cascadelakex/clx-metrics.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
the runtime checks. Instead,
> we can just cast the label (as done with the size calculations earlier)
> to avoid the problem.
>
> Reported-by: William Cohen
> Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified
> string.h functions")
> Cc: sta...
On 08/23/2018 10:31 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Aug 23, 2018 at 01:21:45PM +0200, Martin Liška escreveu:
>> May I please ping this.
>
> I was waiting for someone to give some ack, perhaps Will Cohen can take
> a brief look and provide that? Will?
>
> Thanks,
>
> - Arnaldo
>
>
On 07/10/2018 06:58 PM, Jiri Olsa wrote:
> On Tue, Jul 10, 2018 at 02:27:16PM -0400, William Cohen wrote:
>> Newer versions of GCC perform static analysis to determine whether
>> string truncation is possible with functions such as snprintf and
>> provide a warning if truncat
-8.1.1 in Fedora 28 this causes
the build to fail. The return value of the snprint is now checked to
ensure snprintf produced a NULL-terminated string. If the string for
the path is invalid, the code does attempt to use the string.
Signed-off-by: William Cohen
---
tools/perf/jvmti/jvmti_agent.c | 7
Commit-ID: ea9032fa2e4e91ae15facff5b7c4b2a84c1e40af
Gitweb: https://git.kernel.org/tip/ea9032fa2e4e91ae15facff5b7c4b2a84c1e40af
Author: William Cohen
AuthorDate: Thu, 3 May 2018 15:50:32 -0400
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 7 May 2018 15:23:45 -0300
perf vendor
Signed-off-by: William Cohen
---
tools/perf/pmu-events/arch/x86/mapfile.csv | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/perf/pmu-events/arch/x86/mapfile.csv
b/tools/perf/pmu-events/arch/x86/mapfile.csv
index 93656f2fd53a..7e3cce3bcf3b 100644
--- a/tools/perf/pmu-events/arch/x86
versions of silicon, special case maps can be
added to mapsfile.csv before the general case to handle them.
Signed-off-by: William Cohen
---
tools/perf/arch/arm64/util/header.c | 7 ---
tools/perf/pmu-events/arch/arm64/mapfile.csv | 12 +++-
2 files changed, 7 insertions(+), 12
On 03/15/2018 12:47 PM, John Garry wrote:
> On 15/03/2018 15:53, William Cohen wrote:
>> On 03/07/2018 11:14 PM, Ganapatrao Kulkarni wrote:
>>> On Thu, Mar 8, 2018 at 12:01 AM, William Cohen wrote:
>>>> On 03/07/2018 12:35 PM, Ganapatrao Kulkarni wrote:
>>&
On 03/07/2018 11:14 PM, Ganapatrao Kulkarni wrote:
> On Thu, Mar 8, 2018 at 12:01 AM, William Cohen wrote:
>> On 03/07/2018 12:35 PM, Ganapatrao Kulkarni wrote:
>>> Hi Will Cohen,
>>>
>>> On Wed, Mar 7, 2018 at 8:08 PM, Arnaldo Carvalho de Melo
>>> w
On 03/07/2018 12:35 PM, Ganapatrao Kulkarni wrote:
> Hi Will Cohen,
>
> On Wed, Mar 7, 2018 at 8:08 PM, Arnaldo Carvalho de Melo
> wrote:
>> Em Wed, Mar 07, 2018 at 09:32:05AM -0500, William Cohen escreveu:
>>> On 03/07/2018 06:08 AM, Ganapatrao Kulkarni wrote:
&
On 03/07/2018 10:25 AM, John Garry wrote:
> On 07/03/2018 14:38, Arnaldo Carvalho de Melo wrote:
>> Em Wed, Mar 07, 2018 at 09:32:05AM -0500, William Cohen escreveu:
>>> On 03/07/2018 06:08 AM, Ganapatrao Kulkarni wrote:
>>>> There is MIDR change on ThunderX2 B0, addi
On 03/07/2018 06:08 AM, Ganapatrao Kulkarni wrote:
> There is MIDR change on ThunderX2 B0, adding an entry to mapfile
> to enable JSON events for B0.
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> tools/perf/pmu-events/arch/arm64/mapfile.csv | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --gi
On 03/05/2018 06:24 AM, John Garry wrote:
>>> I am seeing issue(log below) with this patchset on our platfrom.
>>> i have tried using your v2 branch [1]
>>>
>>> root@borg-1>perf_acme>> ./perf --version
>>> perf version 4.16.rc1.g087f7ca
>>> root@borg-1>perf_acme>> ./perf stat -e bus_access_rd sleep
On 03/02/2018 11:35 AM, Ganapatrao Kulkarni wrote:
> Hi John,
>
> On Fri, Mar 2, 2018 at 9:35 PM, William Cohen wrote:
>> On 03/02/2018 03:24 AM, John Garry wrote:
>>> On 27/02/2018 09:50, Jiri Olsa wrote:
>>>> On Sat, Feb 24, 2018 at 12:05:21AM +0800, John G
On 03/02/2018 03:24 AM, John Garry wrote:
> On 27/02/2018 09:50, Jiri Olsa wrote:
>> On Sat, Feb 24, 2018 at 12:05:21AM +0800, John Garry wrote:
>>> This patchset adds support for some perf events features,
>>> targeted at ARM64, implemented in a generic fashion.
>>>
>>> The two main features are a
Commit-ID: 0b7c1528fb741803396da68a9d8d285ff7db731c
Gitweb: https://git.kernel.org/tip/0b7c1528fb741803396da68a9d8d285ff7db731c
Author: William Cohen
AuthorDate: Tue, 30 Jan 2018 22:28:13 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 15 Feb 2018 09:49:44 -0300
perf vendor
Commit-ID: 109def8f4b73a508de947a33c5965f3aa568aee1
Gitweb: https://git.kernel.org/tip/109def8f4b73a508de947a33c5965f3aa568aee1
Author: William Cohen
AuthorDate: Tue, 30 Jan 2018 22:28:13 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 6 Feb 2018 10:11:49 -0300
perf vendor
On 02/01/2018 03:51 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 01, 2018 at 10:12:59AM -0500, William Cohen escreveu:
>> On 02/01/2018 09:43 AM, Arnaldo Carvalho de Melo wrote:
>>> Em Tue, Jan 30, 2018 at 10:28:13PM -0500, William Cohen escreveu:
>>>> Add J
On 02/01/2018 09:43 AM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jan 30, 2018 at 10:28:13PM -0500, William Cohen escreveu:
>> Add JSON metrics for ARM Cortex-A53 Processor
>
> Hi Will, would it be possible to you include an URL for the document
> that served as a reference to
Add JSON metrics for ARM Cortex-A53 Processor
Signed-off-by: William Cohen
---
.../pmu-events/arch/arm64/cortex-a53/branch.json | 27 +++
.../perf/pmu-events/arch/arm64/cortex-a53/bus.json | 22 +
.../pmu-events/arch/arm64/cortex-a53/cache.json| 27 +++
.../pmu
Commit-ID: fbc2844e84038ce3687d203ac80b66194e9f21e6
Gitweb: https://git.kernel.org/tip/fbc2844e84038ce3687d203ac80b66194e9f21e6
Author: William Cohen
AuthorDate: Mon, 4 Dec 2017 09:57:28 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Tue, 5 Dec 2017 15:43:55 -0300
perf vendor
On 12/05/2017 11:13 AM, John Garry wrote:
> This patchset adds support for some perf events features,
> targeted at ARM64, implemented in a generic fashion.
>
> The two main features are as follows:
> - support for arch/vendor/platform pmu events directory structure
> - support for parsing archite
ed to be made for some particular
versions, they can be placed earlier in the mapfile.csv file before
the more general matches.
Signed-off-by: William Cohen
---
tools/perf/pmu-events/arch/powerpc/mapfile.csv | 12 ++--
tools/perf/pmu-events/arch/x86/mapfile.csv | 5 +---
tools/perf/pmu-e
On 11/23/2017 01:06 AM, Ravi Bangoria wrote:
> Hi William,
>
> On 11/23/2017 12:56 AM, Arnaldo Carvalho de Melo wrote:
>> Em Wed, Nov 22, 2017 at 11:08:49AM -0500, William Cohen escreveu:
>>> The powerpc cpuid information includes chip revision information.
>>> C
simulation support
>> arm64: Add kernel return probes support (kretprobes)
>> kprobes: Add arm64 case in kprobe example module
>>
>> William Cohen (1):
>> arm64: Add trampoline code for kretprobes
>
> I applied these patches on top of the arm64 for-next/
On 06/13/2016 12:29 PM, Robert Richter wrote:
> Heiko,
>
> On 09.06.16 11:00:56, Heiko Carstens wrote:
>> However I'm wondering if we shouldn't simply remove at least the s390
>> specific hwswampler code from the oprofile module. This would still leave
>> the common code timer based sampling mode
On 03/01/2016 01:19 PM, Marc Zyngier wrote:
> On 01/03/16 02:57, David Long wrote:
>> From: William Cohen
>>
>> The trampoline code is used by kretprobes to capture a return from a probed
>> function. This is done by saving the registers, calling the handler, and
>
On 12/12/2015 12:56 AM, David Long wrote:
> On 12/11/2015 11:09 AM, William Cohen wrote:
>> On 12/11/2015 12:05 AM, David Long wrote:
>>> There is a moderate amount of code already in kprobes on ARM and the
>>> current ARMv8 patch to deal with conditional exe
On 12/11/2015 12:05 AM, David Long wrote:
> There is a moderate amount of code already in kprobes on ARM and the current
> ARMv8 patch to deal with conditional execution of instructions. One aspect of
> how this is handled is that instructions that fail their predicate and are
> not (technically
On 08/03/2015 09:45 AM, David Long wrote:
> On 08/03/15 09:43, David Long wrote:
>> On 08/03/15 07:09, Will Deacon wrote:
>>> On Thu, Jun 18, 2015 at 04:58:47AM +0100, Pratyush Anand wrote:
These patches have been prepared on top of ARM64 kprobe v7 patches [1].
Keeping as RFC, because kpr
On 07/06/2015 07:37 AM, Masami Hiramatsu wrote:
> On 2015/07/06 18:03, Will Deacon wrote:
>> On Mon, Jul 06, 2015 at 06:03:21AM +0100, Pratyush Anand wrote:
>>> Add all function symbols which are called from do_debug_exception under
>>> NOKPROBE_SYMBOL, as they can not kprobed.
>>
>> It's a shame t
On 06/30/2015 07:04 AM, Steve Capper wrote:
> On 29 June 2015 at 19:16, William Cohen wrote:
>> On 06/29/2015 01:25 PM, Steve Capper wrote:
>>> On 15 June 2015 at 20:07, David Long wrote:
>>>> From: William Cohen
>>>>
>>>> The trampoline
On 06/29/2015 01:25 PM, Steve Capper wrote:
> On 15 June 2015 at 20:07, David Long wrote:
>> From: William Cohen
>>
>> The trampoline code is used by kretprobes to capture a return from a probed
>> function. This is done by saving the registers, calling the ha
On 06/15/2015 03:07 PM, David Long wrote:
> From: William Cohen
>
> The trampoline code is used by kretprobes to capture a return from a probed
> function. This is done by saving the registers, calling the handler, and
> restoring the registers. The code then returns to th
ons.
Experiments with kprobed functions being called in the kprobe handlers showed
that situation was handled appropriately.
There is proposed fix to address the issue with the trampoline, the attached
patch. This is modeled after the way that the x86 handles the kretprobe. The
trampoline d
On 05/13/2015 03:58 PM, David Long wrote:
> On 05/13/15 11:41, William Cohen wrote:
>> On 05/13/2015 05:22 AM, Masami Hiramatsu wrote:
>>> On 2015/05/12 21:48, William Cohen wrote:
>>
>>>> Hi Dave,
>>>>
>>>> In some of the previous
On 05/13/2015 05:22 AM, Masami Hiramatsu wrote:
> On 2015/05/12 21:48, William Cohen wrote:
>> Hi Dave,
>>
>> In some of the previous diagnostic output it looked like things would go
>> wrong
>> in the entry.S when the D bit was cleared and the debug interrupts
On 05/12/2015 01:54 AM, David Long wrote:
> On 05/05/15 11:48, Will Deacon wrote:
>> On Tue, May 05, 2015 at 06:14:51AM +0100, David Long wrote:
>>> On 05/01/15 21:44, William Cohen wrote:
>>>> Dave Long and I did some additional experimentation to better
>>&g
On 05/05/2015 05:02 PM, William Cohen wrote:
> On 05/05/2015 11:48 AM, Will Deacon wrote:
>> On Tue, May 05, 2015 at 06:14:51AM +0100, David Long wrote:
>>> On 05/01/15 21:44, William Cohen wrote:
>>>> Dave Long and I did some additional experimentation to better
>
On 05/05/2015 11:48 AM, Will Deacon wrote:
> On Tue, May 05, 2015 at 06:14:51AM +0100, David Long wrote:
>> On 05/01/15 21:44, William Cohen wrote:
>>> Dave Long and I did some additional experimentation to better
>>> understand what is condition causes t
On 05/05/2015 11:48 AM, Will Deacon wrote:
> On Tue, May 05, 2015 at 06:14:51AM +0100, David Long wrote:
>> On 05/01/15 21:44, William Cohen wrote:
>>> Dave Long and I did some additional experimentation to better
>>> understand what is condition causes t
On 04/29/2015 06:23 AM, Will Deacon wrote:
> On Tue, Apr 28, 2015 at 03:58:21AM +0100, William Cohen wrote:
>> Hi All,
>
> Hi Will,
>
>> I have been experimenting with the patches for arm64 kprobes support.
>> On occasion the kernel gets stuck in a loop printing ou
Hi All,
I have been experimenting with the patches for arm64 kprobes support.
On occasion the kernel gets stuck in a loop printing output:
Unexpected kernel single-step exception at EL1
This message by itself is not that enlighten. I added the attached
patch to get some additional information
On 04/21/2015 07:42 AM, Masami Hiramatsu wrote:
> (2015/04/21 5:19), David Long wrote:
>> From: "David A. Long"
>>
>> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
>> first seen in October 2013. This version attempts to address concerns raised
>> by
>> reviewers and
On 04/21/2015 07:42 AM, Masami Hiramatsu wrote:
> (2015/04/21 5:19), David Long wrote:
>> From: "David A. Long"
>>
>> This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches,
>> first seen in October 2013. This version attempts to address concerns raised
>> by
>> reviewers and
On 03/20/2015 04:20 PM, Peter Zijlstra wrote:
> On Fri, Mar 20, 2015 at 03:41:54PM -0400, William Cohen wrote:
>>
>> There isn't any desire to aggregate the different cgroup data
>> together. The desired grouping is measurements per cgroup, kind of
>> like the pid s
On 03/20/2015 03:22 PM, Peter Zijlstra wrote:
> On Fri, Mar 20, 2015 at 03:10:39PM -0400, William Cohen wrote:
>> cgroup monitoring
>>
>> The cgroup monitoring is built on the perf event per cpu monitoring.
>> If the cgroup is not pinned to a particular set of pro
The current perf event interface avoids complexity in the kernel by
making the user-space responsible for opening a file descriptor for
each cpu to monitor performance events. However, there are two use
cases where this approach has issues: handling system-wide
measurements with hotplug cpus and m
On 01/16/2015 01:29 PM, Zoltan Kiss wrote:
>
>
> On 16/01/15 15:38, William Cohen wrote:
>> On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
>>> Hi,
>>>
>>> I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
>>> and I can se
On 01/16/2015 09:01 AM, Zoltan Kiss wrote:
> Hi,
>
> I'm using OProfile to check some suspicious behaviour of dpdk-pktgen,
> and I can see something which troubles me. Either the scheduler lies
> about core affinity or Oprofile accounts some samples wrongly.
> This userspace app runs in threads,
On 01/12/2015 12:30 PM, Will Deacon wrote:
> On Fri, Jan 09, 2015 at 05:13:29PM +, Pratyush Anand wrote:
>>
>>
>> On Friday 09 January 2015 09:16 PM, Will Deacon wrote:
>>> On Thu, Jan 08, 2015 at 05:28:37PM +, Pratyush Anand wrote:
On Thursday 08 January 2015 09:53 PM, Will Deacon wro
On 12/03/2014 08:16 PM, William Cohen wrote:
> On 12/03/2014 05:54 PM, David Long wrote:
>> On 12/03/14 09:54, William Cohen wrote:
>>> On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
>>>> (2014/11/29 1:01), Steve Capper wrote:
>>>>> On 27 November
On 12/03/2014 05:54 PM, David Long wrote:
> On 12/03/14 09:54, William Cohen wrote:
>> On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
>>> (2014/11/29 1:01), Steve Capper wrote:
>>>> On 27 November 2014 at 06:07, Masami Hiramatsu
>>>> wrote:
>>>&
On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
> (2014/11/29 1:01), Steve Capper wrote:
>> On 27 November 2014 at 06:07, Masami Hiramatsu
>> wrote:
>>> (2014/11/27 3:59), Steve Capper wrote:
The crash is extremely easy to reproduce.
I've not observed any missed events on a kprobe o
On 12/02/2014 02:27 PM, William Cohen wrote:
> Hi Masami and Dave,
>
> I have applied the suggested patch above to my local kernel. However, I have
> noticed systemtap testsuite consistently getting panics when running both
> before AND after applying that patch to the kernel.
On 12/01/2014 04:37 AM, Masami Hiramatsu wrote:
> (2014/11/29 1:01), Steve Capper wrote:
>> On 27 November 2014 at 06:07, Masami Hiramatsu
>> wrote:
>>> (2014/11/27 3:59), Steve Capper wrote:
The crash is extremely easy to reproduce.
I've not observed any missed events on a kprobe o
On 11/18/2014 01:32 AM, David Long wrote:
> From: Sandeepa Prabhu
>
> AArch64 ISA does not instructions to pop PC register value
> from stack(like ARM v7 has ldmia {...,pc}) without using
> one of the general purpose registers. This means return probes
> cannot return to the actual return address
from David A. Long:
> 1) Fix bogus simulate_ldrsw_literal() semantics.
> from Will Cohen:
> 2) Remove PC adjustments when simulating an instruction.
Add missing PC updates for some instruction simulation.
> 3) Fix displacement calculations.
>
> Signed-off-by: Sandeepa Prabhu
&g
Changes since v4:
> from David Long:
> 1) Removed unnecessary addtion of NOP after out-of-line instruction.
> from Will Cohen:
> 2) Disable local irq while executing out of line instruction.
>
> Signed-off-by: Sandeepa Prabhu
> Signed-off-by: William Cohen
> Signed-off
> Changes since v4:
> from David Long:
> 1) Removed unnecessary addtion of NOP after out-of-line instruction.
> from Will Cohen:
> 2) Disable local irq while executing out of line instruction.
>
> Signed-off-by: Sandeepa Prabhu
> Signed-off-by: William Cohen
> Sign
On 05/05/2014 04:04 AM, Ding Tianhong wrote:
> On 2014/4/29 4:39, William Cohen wrote:
>> On 04/27/2014 10:32 PM, Ding Tianhong wrote:
>>> On 2014/4/26 18:22, Ding Tianhong wrote:
>>>> On 2014/4/26 17:23, Catalin Marinas wrote:
>>>>> On 26 Apr 201
robe_mmap() is wrong too by the same reason, fork()
> can race with uprobe_register() and fail for no reason if it wins
> the race and does install_breakpoint() first.
>
> Change mmap_region() and dup_mmap() to ignore the error code from
> uprobe_mmap().
>
> Reported-by: Willi
Andi Kleen wrote:
On Fri, Nov 16, 2007 at 08:00:56AM -0800, Stephane Eranian wrote:
No, he is talking about something similar to what was in perfctr.
The kernel emulates 64-bit counters in software and that is you
get back when you read the counters. If you read via RDPMC, you
get 40 bits. To re
Andi Kleen wrote:
One approach does not prevent the other. Assuming you allow cr4.pce, then
nothing prevents
a self-monitoring thread from reading the counters directly. You'll just get the
lower 32-bit of it. So if you read frequently enough, you should not have a
problem.
Hmm? RDPMC is 64b
Stephane Eranian wrote:
Hello,
On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
Robert Richter wrote:
On 10.11.07 21:32:39, Andi Kleen wrote:
It would be really good to extract a core perfmon and start with
that and then add stuff as it makes sense.
e.g. core perfmon could be
Robert Richter wrote:
On 10.11.07 21:32:39, Andi Kleen wrote:
It would be really good to extract a core perfmon and start with
that and then add stuff as it makes sense.
e.g. core perfmon could be something simple like just support
to context switch state and initialize counters in a basic way
The recent changes in the 2.6.22-rc2 kernel to the write protection of read only
data enable by CONFIG_DEBUG_RODATA prevents kprobes from working. At least on
the on i386 and x86_64 machine the mark_rodata_ro() function marks memory
starting from _text as read only. Thus, when kprobes attempts t
William Cohen wrote:
Hello Stephane,
The oprofile patch should be made against the oprofile cvs rather than
the 0.9.2 tarball. There are some files that the patch touches that are
created by the autogen.sh.
The oprofile patch doesn't build if things are configured without the
&quo
Stephane Eranian wrote:
Hello,
I have released another version of the perfmon new code base package.
This version of the kernel patch is relative to 2.6.20.
This new kernel patch includes the following new features and
bug fixes:
- first cut at supporting Oprofile on i386 and x86-64 ar
After last week's experiment reducing size of task_struct on I was
curious to see what things are using up memory on the system and which
structs have the largest impact on the space used. /proc/slabinfo
provides information about the number objects allocated and their
sizes. With one line script
This past week I was playing around with that pahole tool
(http://oops.ghostprotocols.net:81/acme/dwarves/) and looking at the
size of various struct in the kernel. I was surprised by the size of
the task_struct on x86_64, approaching 4K. I looked through the
fields in task_struct and found that
Christoph Hellwig wrote:
On Tue, Dec 05, 2006 at 12:24:36PM -0500, William Cohen wrote:
Some of the ptrace functions (e.g. ptrace_may_attach in perfmon_syscall.c)
being used in the perfmon kernel patches will go away with the utrace
patches: http://people.redhat.com/roland/utrace/
At least
Stephane Eranian wrote:
Hello,
I have released another version of the perfmon new code base packages.
There is no major updates in this version compared to 061127. This is
a convenience release so that people can use plain 2.6.19.
The perfmon2 kernel changes are:
- fix UP exit bug in
Stephane Eranian wrote:
Hello,
I have released another version of the perfmon new code base package.
This version of the kernel patch is relative to 2.6.19-rc6-git10.
This is a major update because it completes the changes requested
during the code review on LKML. As a consequence, the kernel
Andi Kleen wrote:
On Thursday 16 November 2006 06:05, Andrew Morton wrote:
On Thu, 16 Nov 2006 04:21:09 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
If it's really true that oprofile is simply busted then that's a serious
problem and we should find some way of unbusting it. If that means jus
One of the difficulties function reordering is getting useful data to
figure out a reasonable order for the functions. People do guess wrong
on the frequency of particular functions. Also naive ordering techniques
like just ordering functions based on frequency do not work well.
A North Caroli
Ananth N Mavinakayanahalli wrote:
On Mon, Mar 28, 2005 at 04:10:32PM -0500, William Cohen wrote:
Hi Will,
I found kprobes expects there to be a pre_handler function in the
structure. I was writing a probe that only needed a post_handler
function, no pre_handler function. The probe was tracking
84 matches
Mail list logo
