litmus-rt-pandaboard.git/include/trace/events, branch pandaboard-litmus LITMUS^RT and MC^2 V0 support for the pandaboard. Merge remote-tracking branch 'oneiric-ubuntu/pandaboard' into pandaboard-litmus 2012-09-20T17:33:17+00:00 Christopher Kenna cjk@cs.unc.edu 2012-09-20T17:33:17+00:00 5e0a4919ccb230ab449826ef91bdf38a4ed283e5 Remote branch is from Ubuntu Oneiric (tag Ubuntu-3.0.0-1215.27) with minor patch to the TWL-RTC code. Trying to pull this into LITMUS^RT staging (as of 9/20/2012) to get LITMUS^RT running on the PandaBoard. Conflicts: Makefile fs/exec.c include/linux/fs.h kernel/fork.c 
Remote branch is from Ubuntu Oneiric (tag Ubuntu-3.0.0-1215.27) with
minor patch to the TWL-RTC code. Trying to pull this into LITMUS^RT
staging (as of 9/20/2012) to get LITMUS^RT running on the PandaBoard.

Conflicts:
	Makefile
	fs/exec.c
	include/linux/fs.h
	kernel/fork.c
Subject: [PATCH 034/104] ASoC: core - add platform IO tracing 2012-08-17T08:18:18+00:00 Liam Girdwood lrg@ti.com 2011-07-24T19:59:33+00:00 9da27c16b3fe455345c2434b3f72216c96e0e1e9 Signed-off-by: Liam Girdwood <lrg@ti.com> 
Signed-off-by: Liam Girdwood <lrg@ti.com>
mm: change isolate mode from #define to bitwise type 2012-08-13T13:10:27+00:00 Minchan Kim minchan.kim@gmail.com 2011-11-01T00:06:47+00:00 04dc67d115ca2a3400b384197685b393b86afc0c BugLink: http://bugs.launchpad.net/bugs/1031926 commit 4356f21d09283dc6d39a6f7287a65ddab61e2808 upstream. Stable note: Not tracked in Bugzilla. This patch makes later patches easier to apply but has no other impact. Change ISOLATE_XXX macro with bitwise isolate_mode_t type. Normally, macro isn't recommended as it's type-unsafe and making debugging harder as symbol cannot be passed throught to the debugger. Quote from Johannes " Hmm, it would probably be cleaner to fully convert the isolation mode into independent flags. INACTIVE, ACTIVE, BOTH is currently a tri-state among flags, which is a bit ugly." This patch moves isolate mode from swap.h to mmzone.h by memcontrol.h Signed-off-by: Minchan Kim <minchan.kim@gmail.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Rik van Riel <riel@redhat.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Mel Gorman <mgorman@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> 
BugLink: http://bugs.launchpad.net/bugs/1031926

commit 4356f21d09283dc6d39a6f7287a65ddab61e2808 upstream.

Stable note: Not tracked in Bugzilla. This patch makes later patches
	easier to apply but has no other impact.

Change ISOLATE_XXX macro with bitwise isolate_mode_t type.  Normally,
macro isn't recommended as it's type-unsafe and making debugging harder as
symbol cannot be passed throught to the debugger.

Quote from Johannes
" Hmm, it would probably be cleaner to fully convert the isolation mode
into independent flags.  INACTIVE, ACTIVE, BOTH is currently a
tri-state among flags, which is a bit ugly."

This patch moves isolate mode from swap.h to mmzone.h by memcontrol.h

Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
vmscan: add shrink_slab tracepoints 2012-08-13T13:10:26+00:00 Dave Chinner dchinner@redhat.com 2011-07-08T04:14:34+00:00 16511cd93dd6bfda50c00328739d5826cd742d48 BugLink: http://bugs.launchpad.net/bugs/1031926 commit 095760730c1047c69159ce88021a7fa3833502c8 upstream. Stable note: This patch makes later patches easier to apply but otherwise has little to justify it. It is a diagnostic patch that was part of a series addressing excessive slab shrinking after GFP_NOFS failures. There is detailed information on the series' motivation at https://lkml.org/lkml/2011/6/2/42 . It is impossible to understand what the shrinkers are actually doing without instrumenting the code, so add a some tracepoints to allow insight to be gained. Signed-off-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Mel Gorman <mgorman@suse.de> Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> 
BugLink: http://bugs.launchpad.net/bugs/1031926

commit 095760730c1047c69159ce88021a7fa3833502c8 upstream.

Stable note: This patch makes later patches easier to apply but otherwise
        has little to justify it. It is a diagnostic patch that was part
        of a series addressing excessive slab shrinking after GFP_NOFS
        failures. There is detailed information on the series' motivation
        at https://lkml.org/lkml/2011/6/2/42 .

It is impossible to understand what the shrinkers are actually doing
without instrumenting the code, so add a some tracepoints to allow
insight to be gained.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Add kernel-style events for sched_trace_XXX() functions 2012-03-30T13:39:33+00:00 Andrea Bastoni bastoni@sprg.uniroma2.it 2012-02-11T20:41:19+00:00 26bafa3b7880a323d83b8ea71bdb8e2118a5cba0 Enable kernel-style events (tracepoint) for Litmus. Litmus events trace the same functions as the sched_trace_XXX(), but can be enabled independently. So, why another tracing infrastructure then: - Litmus tracepoints can be recorded and analyzed together (single time reference) with all other kernel tracing events (e.g., sched:sched_switch, etc.). It's easier to correlate the effects of kernel events on litmus tasks. - It enables a quick way to visualize and process schedule traces using trace-cmd utility and kernelshark visualizer. Kernelshark lacks unit-trace's schedule-correctness checks, but it enables a fast view of schedule traces and it has several filtering options (for all kernel events, not only Litmus'). 
Enable kernel-style events (tracepoint) for Litmus. Litmus events
trace the same functions as the sched_trace_XXX(), but can be
enabled independently.

So, why another tracing infrastructure then:
- Litmus tracepoints can be recorded and analyzed together (single
  time reference) with all other kernel tracing events (e.g.,
  sched:sched_switch, etc.). It's easier to correlate the effects
  of kernel events on litmus tasks.

- It enables a quick way to visualize and process schedule traces
  using trace-cmd utility and kernelshark visualizer.
  Kernelshark lacks unit-trace's schedule-correctness checks, but
  it enables a fast view of schedule traces and it has several
  filtering options (for all kernel events, not only Litmus').
writeback: fix dereferencing NULL bdi->dev on trace_writeback_queue 2012-03-08T12:23:33+00:00 Wu Fengguang fengguang.wu@intel.com 2012-02-05T02:54:03+00:00 6a0d42357fbf0d02c76f203d3ffda2b85ad9984e BugLink: http://bugs.launchpad.net/bugs/937915 commit 977b7e3a52a7421ad33a393a38ece59f3d41c2fa upstream. When a SD card is hot removed without umount, del_gendisk() will call bdi_unregister() without destroying/freeing it. This leaves the bdi in the bdi->dev = NULL, bdi->wb.task = NULL, bdi->bdi_list removed state. When sync(2) gets the bdi before bdi_unregister() and calls bdi_queue_work() after the unregister, trace_writeback_queue will be dereferencing the NULL bdi->dev. Fix it with a simple test for NULL. LKML-reference: http://lkml.org/lkml/2012/1/18/346 Reported-by: Rabin Vincent <rabin@rab.in> Tested-by: Namjae Jeon <linkinjeon@gmail.com> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Brad Figg <brad.figg@canonical.com> 
BugLink: http://bugs.launchpad.net/bugs/937915

commit 977b7e3a52a7421ad33a393a38ece59f3d41c2fa upstream.

When a SD card is hot removed without umount, del_gendisk() will call
bdi_unregister() without destroying/freeing it. This leaves the bdi in
the bdi->dev = NULL, bdi->wb.task = NULL, bdi->bdi_list removed state.

When sync(2) gets the bdi before bdi_unregister() and calls
bdi_queue_work() after the unregister, trace_writeback_queue will be
dereferencing the NULL bdi->dev. Fix it with a simple test for NULL.

LKML-reference: http://lkml.org/lkml/2012/1/18/346
Reported-by: Rabin Vincent <rabin@rab.in>
Tested-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: SAUCE: (no-up) vfs: Add a trace point in the mark_inode_dirty function 2011-08-30T17:17:44+00:00 Arjan van de Ven arjan@linux.intel.com 2009-10-25T22:37:04+00:00 962ad0d999aca3c4de598581b671c1fa8d4abd65 [apw@canonical.com: This has no upstream traction but is used by powertop, so its worth carrying.] PowerTOP would like to be able to show who is keeping the disk busy by dirtying data. The most logical spot for this is in the vfs in the mark_inode_dirty() function. Doing this on the block level is not possible because by the time the IO hits the block layer the guilty party can no longer be found ("kjournald" and "pdflush" are not useful answers to "who caused this file to be dirty). The trace point follows the same logic/style as the block_dump code and pretty much dumps the same data, just not to dmesg (and thus to /var/log/messages) but via the trace events streams. Note: This patch was posted to lkml and might potentially go into 2.6.33 but I have not seen which maintainer will take it. Signed-of-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> 
[apw@canonical.com: This has no upstream traction but is used by powertop,
so its worth carrying.]

PowerTOP would like to be able to show who is keeping the disk
busy by dirtying data. The most logical spot for this is in the vfs
in the mark_inode_dirty() function. Doing this on the block level
is not possible because by the time the IO hits the block layer the
guilty party can no longer be found ("kjournald" and "pdflush" are not
useful answers to "who caused this file to be dirty).

The trace point follows the same logic/style as the block_dump code
and pretty much dumps the same data, just not to dmesg (and thus to
/var/log/messages) but via the trace events streams.

Note: This patch was posted to lkml and might potentially go into 2.6.33 but I
have not seen which maintainer will take it.

Signed-of-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Amit Kucheria <amit.kucheria@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
UBUNTU: SAUCE: (no-up) trace: add trace events for open(), exec() and uselib() 2011-08-30T17:14:25+00:00 Scott James Remnant scott@ubuntu.com 2009-10-27T10:05:32+00:00 00ccd94c860ce08ac0976a93159a2616b0bcf34b BugLink: http://bugs.launchpad.net/bugs/462111 This patch uses TRACE_EVENT to add tracepoints for the open(), exec() and uselib() syscalls so that ureadahead can cheaply trace the boot sequence to determine what to read to speed up the next. It's not upstream because it will need to be rebased onto the syscall trace events whenever that gets merged, and is a stop-gap. Signed-off-by: Scott James Remnant <scott@ubuntu.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com> 
BugLink: http://bugs.launchpad.net/bugs/462111

This patch uses TRACE_EVENT to add tracepoints for the open(),
exec() and uselib() syscalls so that ureadahead can cheaply trace
the boot sequence to determine what to read to speed up the next.

It's not upstream because it will need to be rebased onto the syscall
trace events whenever that gets merged, and is a stop-gap.

Signed-off-by: Scott James Remnant <scott@ubuntu.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 2011-06-21T17:22:35+00:00 Linus Torvalds torvalds@linux-foundation.org 2011-06-21T17:22:35+00:00 890879cfa08f5ceaa09810611f46e890f7d57ff6 * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: jbd2: Fix oops in jbd2_journal_remove_journal_head() jbd2: Remove obsolete parameters in the comments for some jbd2 functions ext4: fixed tracepoints cleanup ext4: use FIEMAP_EXTENT_LAST flag for last extent in fiemap ext4: Fix max file size and logical block counting of extent format file ext4: correct comments for ext4_free_blocks() 
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  jbd2: Fix oops in jbd2_journal_remove_journal_head()
  jbd2: Remove obsolete parameters in the comments for some jbd2 functions
  ext4: fixed tracepoints cleanup
  ext4: use FIEMAP_EXTENT_LAST flag for last extent in fiemap
  ext4: Fix max file size and logical block counting of extent format file
  ext4: correct comments for ext4_free_blocks()
Merge branch 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip 2011-06-19T15:56:56+00:00 Linus Torvalds torvalds@linux-foundation.org 2011-06-19T15:56:56+00:00 357ed6b1a110048ff8106f99092d6c4a7aadb45a * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: rcu: Move RCU_BOOST #ifdefs to header file rcu: use softirq instead of kthreads except when RCU_BOOST=y rcu: Use softirq to address performance regression rcu: Simplify curing of load woes 
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  rcu: Move RCU_BOOST #ifdefs to header file
  rcu: use softirq instead of kthreads except when RCU_BOOST=y
  rcu: Use softirq to address performance regression
  rcu: Simplify curing of load woes