- 10 7月, 2009 1 次提交
-
-
由 Maynard Johnson 提交于
The bt_lost_no_mapping is not getting reset at the start of a profiling run, thus the oprofiled.log shows erroneous values for this statistic. The attached patch fixes this problem. Signed-off-by: NMaynard Johnson <maynardj@us.ibm.com> Signed-off-by: NRobert Richter <robert.richter@amd.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 16 10月, 2008 2 次提交
-
-
由 Robert Richter 提交于
Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
由 Robert Richter 提交于
Signed-off-by: NRobert Richter <robert.richter@amd.com>
-
- 28 4月, 2008 1 次提交
-
-
由 Mike Travis 提交于
Change cpu_buffer from array to per_cpu variable in oprofile functions. [akpm@linux-foundation.org: coding-style fixes] Cc: Philippe Elie <phil.el@wanadoo.fr> Signed-off-by: NMike Travis <travis@sgi.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 15 11月, 2007 1 次提交
-
-
由 Philippe Elie 提交于
Instruction pointer returned by profile_pc() can be a random value. This break the assumption than we can safely set struct op_sample.eip field to a magic value to signal to the per-cpu buffer reader side special event like task switch ending up in a segfault in get_task_mm() when profile_pc() return ~0UL. Fixed by sanitizing the sampled eip and reject/log invalid eip. Problem reported by Sami Farin, patch tested by him. Signed-off-by: NPhilippe Elie <phil.el@wanadoo.fr> Tested-by: NSami Farin <safari-kernel@safari.iki.fi> Cc: <stable@kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 3月, 2006 1 次提交
-
-
由 KAMEZAWA Hiroyuki 提交于
This patch replaces for_each_cpu with for_each_possible_cpu. Signed-off-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-