)]}'
{
  "commit": "2fad6f5deee5556f511eab58da78737a23ddb35d",
  "tree": "eca8262062c4fda63cb3bd34f9478f3fbfd7f518",
  "parents": [
    "70ac23cfa31f68289d4b720c6162b3929ab4de36"
  ],
  "author": {
    "name": "Wu Fengguang",
    "email": "fengguang.wu@intel.com",
    "time": "Tue Jun 16 15:31:29 2009 -0700"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@linux-foundation.org",
    "time": "Tue Jun 16 19:47:29 2009 -0700"
  },
  "message": "readahead: enforce full readahead size on async mmap readahead\n\nWe need this in one particular case and two more general ones.\n\nNow we do async readahead for sequential mmap reads, and do it with the\nhelp of PG_readahead.  For normal reads, PG_readahead is the sufficient\ncondition to do a sequential readahead.  But unfortunately, for mmap\nreads, there is a tiny nuisance:\n\n[11736.998347] readahead-init0(process: sh/23926, file: sda1/w3m, offset\u003d0:4503599627370495, ra\u003d0+4-3) \u003d 4\n[11737.014985] readahead-around(process: w3m/23926, file: sda1/w3m, offset\u003d0:0, ra\u003d290+32-0) \u003d 17\n[11737.019488] readahead-around(process: w3m/23926, file: sda1/w3m, offset\u003d0:0, ra\u003d118+32-0) \u003d 32\n[11737.024921] readahead-interleaved(process: w3m/23926, file: sda1/w3m, offset\u003d0:2, ra\u003d4+6-6) \u003d 6\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                 ~~~~~~~~~~~~~\n\nAn unfavorably small readahead.  The original dumb read-around size could\nbe more efficient.\n\nThat happened because ld-linux.so does a read(832) in L1 before mmap(),\nwhich triggers a 4-page readahead, with the second page tagged\nPG_readahead.\n\nL0: open(\"/lib/libc.so.6\", O_RDONLY)        \u003d 3\nL1: read(3, \"\\177ELF\\2\\1\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\3\\0\u003e\\0\\1\\0\\0\\0\\340\\342\"..., 832) \u003d 832\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nL2: fstat(3, {st_mode\u003dS_IFREG|0755, st_size\u003d1420624, ...}) \u003d 0\nL3: mmap(NULL, 3527256, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) \u003d 0x7fac6e51d000\nL4: mprotect(0x7fac6e671000, 2097152, PROT_NONE) \u003d 0\nL5: mmap(0x7fac6e871000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x154000) \u003d 0x7fac6e871000\nL6: mmap(0x7fac6e876000, 16984, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) \u003d 0x7fac6e876000\nL7: close(3)                                \u003d 0\n\nIn general, the PG_readahead flag will also be hit in cases\n\n- sequential reads\n\n- clustered random reads\n\nA full readahead size is desirable in both cases.\n\nCc: Nick Piggin \u003cnpiggin@suse.de\u003e\nSigned-off-by: Wu Fengguang \u003cfengguang.wu@intel.com\u003e\nCc: Ying Han \u003cyinghan@google.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "99977f0a94e4719f9a3644ff018aa35ea3cfbc6f",
      "old_mode": 33188,
      "old_path": "mm/filemap.c",
      "new_id": "5c0c6518f3411a68cc2abb3881e73e42eaf473a8",
      "new_mode": 33188,
      "new_path": "mm/filemap.c"
    }
  ]
}