UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/include/trace/events/tlb.h

62 lines
1.4 KiB
C
Raw Normal View History

x86/mm: Add tracepoints for TLB flushes We don't have any good way to figure out what kinds of flushes are being attempted. Right now, we can try to use the vm counters, but those only tell us what we actually did with the hardware (one-by-one vs full) and don't tell us what was actually _requested_. This allows us to select out "interesting" TLB flushes that we might want to optimize (like the ranged ones) and ignore the ones that we have very little control over (the ones at context switch). Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: http://lkml.kernel.org/r/20140731154059.4C96CBA5@viggo.jf.intel.com Acked-by: Rik van Riel <riel@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-07-31 23:40:59 +08:00
#undef TRACE_SYSTEM
#define TRACE_SYSTEM tlb
#if !defined(_TRACE_TLB_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_TLB_H
#include <linux/mm_types.h>
#include <linux/tracepoint.h>
x86/tlb/trace: Export enums in used by tlb_flush tracepoint Have the enums used in __print_symbolic() by the trace_tlb_flush() tracepoint exported to userpace such that they can be parsed by userspace tools. Link: http://lkml.kernel.org/r/20150403013802.220157513@goodmis.org Cc: Dave Hansen <dave@sr71.net> Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2015-03-25 06:15:57 +08:00
#define TLB_FLUSH_REASON \
EM( TLB_FLUSH_ON_TASK_SWITCH, "flush on task switch" ) \
EM( TLB_REMOTE_SHOOTDOWN, "remote shootdown" ) \
EM( TLB_LOCAL_SHOOTDOWN, "local shootdown" ) \
x86, mm: trace when an IPI is about to be sent When unmapping pages it is necessary to flush the TLB. If that page was accessed by another CPU then an IPI is used to flush the remote CPU. That is a lot of IPIs if kswapd is scanning and unmapping >100K pages per second. There already is a window between when a page is unmapped and when it is TLB flushed. This series increases the window so multiple pages can be flushed using a single IPI. This should be safe or the kernel is hosed already. Patch 1 simply made the rest of the series easier to write as ftrace could identify all the senders of TLB flush IPIS. Patch 2 tracks what CPUs potentially map a PFN and then sends an IPI to flush the entire TLB. Patch 3 tracks when there potentially are writable TLB entries that need to be batched differently Patch 4 increases SWAP_CLUSTER_MAX to further batch flushes The performance impact is documented in the changelogs but in the optimistic case on a 4-socket machine the full series reduces interrupts from 900K interrupts/second to 60K interrupts/second. This patch (of 4): It is easy to trace when an IPI is received to flush a TLB but harder to detect what event sent it. This patch makes it easy to identify the source of IPIs being transmitted for TLB flushes on x86. Signed-off-by: Mel Gorman <mgorman@suse.de> Reviewed-by: Rik van Riel <riel@redhat.com> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-09-05 06:47:29 +08:00
EM( TLB_LOCAL_MM_SHOOTDOWN, "local mm shootdown" ) \
EMe( TLB_REMOTE_SEND_IPI, "remote ipi send" )
x86/tlb/trace: Export enums in used by tlb_flush tracepoint Have the enums used in __print_symbolic() by the trace_tlb_flush() tracepoint exported to userpace such that they can be parsed by userspace tools. Link: http://lkml.kernel.org/r/20150403013802.220157513@goodmis.org Cc: Dave Hansen <dave@sr71.net> Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2015-03-25 06:15:57 +08:00
/*
* First define the enums in TLB_FLUSH_REASON to be exported to userspace
* via TRACE_DEFINE_ENUM().
*/
#undef EM
#undef EMe
#define EM(a,b) TRACE_DEFINE_ENUM(a);
#define EMe(a,b) TRACE_DEFINE_ENUM(a);
TLB_FLUSH_REASON
/*
* Now redefine the EM() and EMe() macros to map the enums to the strings
* that will be printed in the output.
*/
#undef EM
#undef EMe
#define EM(a,b) { a, b },
#define EMe(a,b) { a, b }
x86/mm: Add tracepoints for TLB flushes We don't have any good way to figure out what kinds of flushes are being attempted. Right now, we can try to use the vm counters, but those only tell us what we actually did with the hardware (one-by-one vs full) and don't tell us what was actually _requested_. This allows us to select out "interesting" TLB flushes that we might want to optimize (like the ranged ones) and ignore the ones that we have very little control over (the ones at context switch). Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: http://lkml.kernel.org/r/20140731154059.4C96CBA5@viggo.jf.intel.com Acked-by: Rik van Riel <riel@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-07-31 23:40:59 +08:00
tracing: Remove duplicate checks for online CPUs Some trace events have conditions that check if the current CPU is online or not before recording the tracepoint. That's because certain trace events are in locations that can be called as the CPU is going offline and when RCU no longer monitors it (like kfree and friends). The check was added because trace events require RCU to be active. This is a trace event infrastructure issue and not something that individual trace events should worry about. The tracepoint.h code now has added a check to see if the current CPU is considered online, and it only does the tracepoint if it is. There's no more need for individual trace events to also include this check. It is now redundant. Cc: Shreyas B. Prabhu <shreyas@linux.vnet.ibm.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2016-02-20 02:59:54 +08:00
TRACE_EVENT(tlb_flush,
x86/mm: Add tracepoints for TLB flushes We don't have any good way to figure out what kinds of flushes are being attempted. Right now, we can try to use the vm counters, but those only tell us what we actually did with the hardware (one-by-one vs full) and don't tell us what was actually _requested_. This allows us to select out "interesting" TLB flushes that we might want to optimize (like the ranged ones) and ignore the ones that we have very little control over (the ones at context switch). Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Link: http://lkml.kernel.org/r/20140731154059.4C96CBA5@viggo.jf.intel.com Acked-by: Rik van Riel <riel@redhat.com> Cc: Mel Gorman <mgorman@suse.de> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-07-31 23:40:59 +08:00
TP_PROTO(int reason, unsigned long pages),
TP_ARGS(reason, pages),
TP_STRUCT__entry(
__field( int, reason)
__field(unsigned long, pages)
),
TP_fast_assign(
__entry->reason = reason;
__entry->pages = pages;
),
TP_printk("pages:%ld reason:%s (%d)",
__entry->pages,
__print_symbolic(__entry->reason, TLB_FLUSH_REASON),
__entry->reason)
);
#endif /* _TRACE_TLB_H */
/* This part must be outside protection */
#include <trace/define_trace.h>