)]}'
{
  "commit": "ef710e100c1068d3dd5774d2b34c5485219e06ce",
  "tree": "ed295053a31de472d4ed4338679c00ac8e8437c7",
  "parents": [
    "bc289ae98b75d93228d24f521ef02a076e506e94"
  ],
  "author": {
    "name": "KOSAKI Motohiro",
    "email": "kosaki.motohiro@jp.fujitsu.com",
    "time": "Thu Jul 01 14:34:35 2010 +0900"
  },
  "committer": {
    "name": "Steven Rostedt",
    "email": "rostedt@goodmis.org",
    "time": "Wed Jul 21 10:20:17 2010 -0400"
  },
  "message": "tracing: Shrink max latency ringbuffer if unnecessary\n\nDocumentation/trace/ftrace.txt says\n\n  buffer_size_kb:\n\n        This sets or displays the number of kilobytes each CPU\n        buffer can hold. The tracer buffers are the same size\n        for each CPU. The displayed number is the size of the\n        CPU buffer and not total size of all buffers. The\n        trace buffers are allocated in pages (blocks of memory\n        that the kernel uses for allocation, usually 4 KB in size).\n        If the last page allocated has room for more bytes\n        than requested, the rest of the page will be used,\n        making the actual allocation bigger than requested.\n        ( Note, the size may not be a multiple of the page size\n          due to buffer management overhead. )\n\n        This can only be updated when the current_tracer\n        is set to \"nop\".\n\nBut it\u0027s incorrect. currently total memory consumption is\n\u0027buffer_size_kb x CPUs x 2\u0027.\n\nWhy two times difference is there? because ftrace implicitly allocate\nthe buffer for max latency too.\n\nThat makes sad result when admin want to use large buffer. (If admin\nwant full logging and makes detail analysis). example, If admin\nhave 24 CPUs machine and write 200MB to buffer_size_kb, the system\nconsume ~10GB memory (200MB x 24 x 2). umm.. 5GB memory waste is\nusually unacceptable.\n\nFortunatelly, almost all users don\u0027t use max latency feature.\nThe max latency buffer can be disabled easily.\n\nThis patch shrink buffer size of the max latency buffer if\nunnecessary.\n\nSigned-off-by: KOSAKI Motohiro \u003ckosaki.motohiro@jp.fujitsu.com\u003e\nLKML-Reference: \u003c20100701104554.DA2D.A69D9226@jp.fujitsu.com\u003e\nSigned-off-by: Steven Rostedt \u003crostedt@goodmis.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "af9042977c086020e3bb6cee7fadc464ca634f29",
      "old_mode": 33188,
      "old_path": "kernel/trace/trace.c",
      "new_id": "f7488f44d26babd796d8b0fd5079d4eaeb8206a5",
      "new_mode": 33188,
      "new_path": "kernel/trace/trace.c"
    },
    {
      "type": "modify",
      "old_id": "7778f067fc8bff8215ed2a124174b997e4e87200",
      "old_mode": 33188,
      "old_path": "kernel/trace/trace.h",
      "new_id": "cb629b3b108c501648bd2a4ba855f5489d780a12",
      "new_mode": 33188,
      "new_path": "kernel/trace/trace.h"
    },
    {
      "type": "modify",
      "old_id": "6fd486e0cef407b1cf3c416d15c31be14bf8dd6a",
      "old_mode": 33188,
      "old_path": "kernel/trace/trace_irqsoff.c",
      "new_id": "73a6b0601f2e301c0cd5575cc96f7f0b788853d9",
      "new_mode": 33188,
      "new_path": "kernel/trace/trace_irqsoff.c"
    },
    {
      "type": "modify",
      "old_id": "c9fd5bd02036d85db3474d4b6cc5b1761f4e572a",
      "old_mode": 33188,
      "old_path": "kernel/trace/trace_sched_wakeup.c",
      "new_id": "4086eae6e81b1c1b9762edc01600d3294c6bc130",
      "new_mode": 33188,
      "new_path": "kernel/trace/trace_sched_wakeup.c"
    }
  ]
}