18 Sep, 2009
1 commit
-
commit 85bac32c4a52c592b857f2c360cc5ec93a097d70
ring-buffer: only enable ring_buffer_swap_cpu when needed
broke oprofile (at least on s390, but likely on all platforms).this patch lets oprofile select RING_BUFER_ALLOW_SWAP to make
ring_buffer_swap_cpu usable for oprofile.Signed-off-by: Christian Borntraeger
LKML-Reference:
Cc: Ingo Molnar
Cc: Robert Richter
Signed-off-by: Steven Rostedt
20 Jul, 2009
1 commit
-
The number of hardware counters is limited. The multiplexing feature
enables OProfile to gather more events than counters are provided by
the hardware. This is realized by switching between events at an user
specified time interval.A new file (/dev/oprofile/time_slice) is added for the user to specify
the timer interval in ms. If the number of events to profile is higher
than the number of hardware counters available, the patch will
schedule a work queue that switches the event counter and re-writes
the different sets of values into it. The switching mechanism needs to
be implemented for each architecture to support multiplexing. This
patch only implements AMD CPU support, but multiplexing can be easily
extended for other models and architectures.There are follow-on patches that rework parts of this patch.
Signed-off-by: Jason Yeh
Signed-off-by: Robert Richter
19 Jun, 2009
1 commit
-
Enable the use of GCC's coverage testing tool gcov [1] with the Linux
kernel. gcov may be useful for:* debugging (has this code been reached at all?)
* test improvement (how do I change my test to cover these lines?)
* minimizing kernel configurations (do I need this option if the
associated code is never run?)The profiling patch incorporates the following changes:
* change kbuild to include profiling flags
* provide functions needed by profiling code
* present profiling data as files in debugfsNote that on some architectures, enabling gcc's profiling option
"-fprofile-arcs" for the entire kernel may trigger compile/link/
run-time problems, some of which are caused by toolchain bugs and
others which require adjustment of architecture code.For this reason profiling the entire kernel is initially restricted
to those architectures for which it is known to work without changes.
This restriction can be lifted once an architecture has been tested
and found compatible with gcc's profiling. Profiling of single files
or directories is still available on all platforms (see config help
text).[1] http://gcc.gnu.org/onlinedocs/gcc/Gcov.html
Signed-off-by: Peter Oberparleiter
Cc: Andi Kleen
Cc: Huang Ying
Cc: Li Wei
Cc: Michael Ellerman
Cc: Ingo Molnar
Cc: Heiko Carstens
Cc: Martin Schwidefsky
Cc: Rusty Russell
Cc: WANG Cong
Cc: Sam Ravnborg
Cc: Jeff Dike
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
10 Apr, 2009
1 commit
-
Impact: performance regression fix for s390
The adaptive spinning mutexes will not always do what one would expect on
virtualized architectures like s390. Especially the cpu_relax() loop in
mutex_spin_on_owner might hurt if the mutex holding cpu has been scheduled
away by the hypervisor.We would end up in a cpu_relax() loop when there is no chance that the
state of the mutex changes until the target cpu has been scheduled again by
the hypervisor.For that reason we should change the default behaviour to no-spin on s390.
We do have an instruction which allows to yield the current cpu in favour of
a different target cpu. Also we have an instruction which allows us to figure
out if the target cpu is physically backed.However we need to do some performance tests until we can come up with
a solution that will do the right thing on s390.Signed-off-by: Heiko Carstens
Acked-by: Peter Zijlstra
Cc: Martin Schwidefsky
Cc: Christian Borntraeger
LKML-Reference:
Signed-off-by: Ingo Molnar
02 Apr, 2009
1 commit
-
Conflicts:
include/linux/slub_def.h
lib/Kconfig.debug
mm/slob.c
mm/slub.c
06 Mar, 2009
1 commit
-
Clean up menu structure, introduce TRACING_SUPPORT switch that signals
whether an architecture supports various instrumentation mechanisms.Signed-off-by: Ingo Molnar
05 Mar, 2009
1 commit
-
Impact: add a Kconfig entry for DMA-API debugging
Signed-off-by: Joerg Roedel
14 Jan, 2009
1 commit
-
From: Martin Schwidefsky
By selecting HAVE_SYSCALL_WRAPPERS architectures can activate
system call wrappers in order to sign extend system call arguments.All architectures where the ABI defines that the caller of a function
has to perform sign extension probably need this.Reported-by: Christian Borntraeger
Acked-by: Ralf Baechle
Signed-off-by: Martin Schwidefsky
Signed-off-by: Heiko Carstens
12 Dec, 2008
1 commit
-
Impact: build fix
OProfile now depends on the ring buffer infrastructure:
arch/x86/oprofile/built-in.o: In function `oprofile_add_ibs_sample':
: undefined reference to `ring_buffer_unlock_commit'Select TRACING and RING_BUFFER when oprofile is enabled.
Signed-off-by: Ingo Molnar
01 Dec, 2008
1 commit
-
All architectures now use the generic compat_sys_ptrace, as should every
new architecture that needs 32bit compat (if we'll ever get another).Remove the now superflous __ARCH_WANT_COMPAT_SYS_PTRACE define, and also
kill a comment about __ARCH_SYS_PTRACE that was added after
__ARCH_SYS_PTRACE was already gone.Signed-off-by: Christoph Hellwig
Acked-by: David S. Miller
Signed-off-by: Linus Torvalds
28 Oct, 2008
1 commit
-
Fixes screwing up text output when doing a make oldconfig and viewing
help text of "OProfile AMD IBS support". When the terminal is
not using an UTF8 locale / LANG. "make config" breaks terminal output
and its not possible to continue.(Change added by changeset 852402cc Tue Jul 22 21:09:06 2008)
Signed-off-by: Jesper Dangaard Brouer
Signed-off-by: Robert Richter
17 Oct, 2008
1 commit
-
Using "def_bool n" is pointless, simply using bool here appears more
appropriate.Further, retaining such options that don't have a prompt and aren't
selected by anything seems also at least questionable.Signed-off-by: Jan Beulich
Cc: Ingo Molnar
Cc: Tony Luck
Cc: Thomas Gleixner
Cc: Bartlomiej Zolnierkiewicz
Cc: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Oct, 2008
1 commit
-
Conflicts:
arch/x86/kernel/apic_32.c
arch/x86/oprofile/nmi_int.c
include/linux/pci_ids.h
27 Jul, 2008
1 commit
-
This adds the generic HAVE_ARCH_TRACEHOOK kconfig item. Each arch should
add to some Kconfig file:select HAVE_ARCH_TRACEHOOK
if the arch code uses all the latest hooks to enable newfangled tracing
and debugging code. The comment in arch/Kconfig lists all the
prerequisite arch support. When all these are available, setting
HAVE_ARCH_TRACEHOOK will allow enabling any new features that depend on
the modern arch interfaces.Signed-off-by: Roland McGrath
Cc: Oleg Nesterov
Reviewed-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jul, 2008
2 commits
-
Signed-off-by: Robert Richter
Cc: oprofile-list
Cc: Robert Richter
Cc: Barry Kasindorf
Signed-off-by: Ingo Molnar -
In many cases, especially in networking, it can be beneficial to know at
compile time whether the architecture can do unaligned accesses efficiently.
This patch introduces a new Kconfig symbolHAVE_EFFICIENT_UNALIGNED_ACCESS
for that purpose and adds it to the powerpc and x86 architectures. Also add
some documentation about alignment and networking, and especially one intended
use of this symbol.Signed-off-by: Johannes Berg
Acked-by: Sam Ravnborg
Acked-by: Ingo Molnar [x86 architecture part]
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jul, 2008
2 commits
-
In order to be able to debug things like the X server and programs using
the PPC Cell SPUs, the debugger needs to be able to access device memory
through ptrace and /proc/pid/mem.This patch:
Add the generic_access_phys access function and put the hooks in place
to allow access_process_vm to access device or PPC Cell SPU memory.[riel@redhat.com: Add documentation for the vm_ops->access function]
Signed-off-by: Rik van Riel
Signed-off-by: Benjamin Herrensmidt
Cc: Dave Airlie
Cc: Hugh Dickins
Cc: Paul Mackerras
Cc: Arnd Bergmann
Acked-by: Peter Zijlstra
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Flag platforms as HAVE_CLK (or not) in Kconfig, based on whether they
support calls, so that otherwise portable drivers which need
those calls can list that dependency.Something like this is a prerequisite for merging the musb_hdrc driver,
currently used on platforms including Davinci, OMAP2430, OMAP3xx ... and
the discrete TUSB6010 chip, which doesn't have a natural platform
dependency. (Used with OMAP 2420 in current Nokia N8x0 tablets.)Signed-off-by: David Brownell
Cc: Russell King
Acked-by: Haavard Skinnemoen
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Paul Mundt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
26 Jun, 2008
1 commit
-
This adds kernel/smp.c which contains helpers for IPI function calls. In
addition to supporting the existing smp_call_function() in a more efficient
manner, it also adds a more scalable variant called smp_call_function_single()
for calling a given function on a single CPU only.The core of this is based on the x86-64 patch from Nick Piggin, lots of
changes since then. "Alan D. Brunelle" has
contributed lots of fixes and suggestions as well. Also thanks to
Paul E. McKenney for reviewing RCU usage
and getting rid of the data allocation fallback deadlock.Acked-by: Ingo Molnar
Reviewed-by: Paul E. McKenney
Signed-off-by: Jens Axboe
29 Apr, 2008
1 commit
-
Introduce new interfaces, dma_*map*_attrs(), for passing architecture-specific
attributes when memory is mapped and unmapped for DMA. Give the interfaces
default implementations which ignore attributes. Also introduce the
dma_{set|get}_attr() interfaces for setting and retrieving individual
attributes. Define one attribute, DMA_ATTR_WRITE_BARRIER, in anticipation of
its use by ia64/sn. Select whether architectures implement arch-specific
versions of the dma_*map*_attrs() interfaces via HAVE_DMA_ATTRS in Kconfig.[markn@au1.ibm.com: dma_{set,get}_attr() have to be static inline]
Signed-off-by: Arthur Kepner
Cc: Tony Luck
Cc: Jesse Barnes
Cc: Jes Sorensen
Cc: Randy Dunlap
Cc: Roland Dreier
Cc: James Bottomley
Cc: David Miller
Cc: Benjamin Herrenschmidt
Cc: Grant Grundler
Cc: Michael Ellerman
Signed-off-by: Mark Nelson
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
05 Mar, 2008
1 commit
-
Add CONFIG_HAVE_KRETPROBES to the arch//Kconfig file for relevant
architectures with kprobes support. This facilitates easy handling of
in-kernel modules (like samples/kprobes/kretprobe_example.c) that depend on
kretprobes being present in the kernel.Thanks to Sam Ravnborg for helping make the patch more lean.
Per Mathieu's suggestion, added CONFIG_KRETPROBES and fixed up dependencies.
Signed-off-by: Ananth N Mavinakayanahalli
Acked-by: Mathieu Desnoyers
Acked-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
03 Feb, 2008
2 commits
-
Move the instrumentation Kconfig to
arch/Kconfig for architecture dependent options
- oprofile
- kprobesand
init/Kconfig for architecture independent options
- profiling
- markersRemove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the kernel/Kconfig.instrumentation file.Signed-off-by: Mathieu Desnoyers
Cc: Linus Torvalds
Cc:
Signed-off-by: Sam Ravnborg -
Puts the content of arch/Kconfig in the "General setup" menu.
Linus:
> Should it come with a re-duplication of it's content into each
> architecture, which was the case previously ? The oprofile and kprobes
> menu entries were litteraly cut and pasted from one architecture to
> another. Should we put its content in init/Kconfig then ?I don't think it's a good idea to go back to making it per-architecture,
although that extensive "depends on " might
indicate that there certainly is room for cleanup there.And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I
just think it's wrong to (a) lump the code together when it really doesn't
necessarily need to and (b) show it to users as some kind of choice that
is tied together (whether it then has common code or not).On the per-architecture side, I do think it would be better to *not* have
internal architecture knowledge in a generic file, and as such a line likedepends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
really shouldn't exist in a file like kernel/Kconfig.instrumentation.
It would be much better to do
depends on ARCH_SUPPORTS_KPROBES
in that generic file, and then architectures that do support it would just
have abool ARCH_SUPPORTS_KPROBES
default yin *their* architecture files. That would seem to be much more logical,
and is readable both for arch maintainers *and* for people who have no
clue - and don't care - about which architecture is supposed to support
which interface...Sam Ravnborg:
Stuff it into a new file: arch/Kconfig
We can then extend this file to include all the 'trailing'
Kconfig things that are anyway equal for all ARCHs.But it should be kept clean - so if we introduce such a file
then we should use ARCH_HAS_whatever in the arch specific Kconfig
files to enable stuff that is not shared.[...]
The above suggestion is actually not exactly the best way to do it...
First the naming..
A quick grep shows following usage today (in Kconfig files)
ARCH_HAS 51
ARCH_SUPPORTS 4
HAVE_ARCH 7ARCH_HAS is the clear winner.
In the common Kconfig file do:
config FOO
depends on ARCH_HAS_FOO
bool "bla bla"config ARCH_HAS_FOO
def_bool nIn the arch specific Kconfig file in a suitable place do:
config SUITABLE_OPTION
select ARCH_HAS_FOOThe naming of ARCH_HAS_ is fixed and shall be:
ARCH_HAS_Only a single line added pr. architecture.
And we will end up with a (maybe even commented) list of trivial selects.- Yet another update :
Moving to HAVE_* now.
Signed-off-by: Mathieu Desnoyers
Cc: Jeff Dike
Cc: David Howells
Cc: Ananth N Mavinakayanahalli
Signed-off-by: Sam Ravnborg
