)]}'
{
  "log": [
    {
      "commit": "3f4bb1f4199b7dc0c958447b1e4898980013b884",
      "tree": "3d8aacfc6b7bbf7b2d224ae10ca693c55c64739e",
      "parents": [
        "0811bab24ff1eecab38110eda7ea7847db95c64e"
      ],
      "author": {
        "name": "Eric Dumazet",
        "email": "dada1@cosmosbay.com",
        "time": "Tue Sep 06 15:18:16 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Wed Sep 07 16:57:41 2005 -0700"
      },
      "message": "[PATCH] struct dentry: place d_hash close to d_parent and d_name to speedup lookups\n\ndentry cache uses sophisticated RCU technology (and prefetching if\navailable) but touches 2 cache lines per dentry during hlist lookup.\n\nThis patch moves d_hash in the same cache line than d_parent and d_name\nfields so that :\n\n1) One cache line is needed instead of two.\n\n2) the hlist_for_each_rcu() prefetching has a chance to bring all the\n   needed data in advance, not only the part that includes d_hash.next.\n\nI also changed one old comment that was wrong for 64bits.\n\nA further optimisation would be to separate dentry in two parts, one that\nis mostly read, and one writen (d_count/d_lock) to avoid false sharing on\nSMP/NUMA but this would need different field placement depending on 32bits\nor 64bits platform.\n\nSigned-off-by: Eric Dumazet \u003cdada1@cosmosbay.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
      "tree": "0bba044c4ce775e45a88a51686b5d9f90697ea9d",
      "parents": [],
      "author": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sat Apr 16 15:20:36 2005 -0700"
      },
      "message": "Linux-2.6.12-rc2\n\nInitial git repository build. I\u0027m not bothering with the full history,\neven though we have it. We can create a separate \"historical\" git\narchive of that later if we want to, and in the meantime it\u0027s about\n3.2GB when imported into git - space that would just make the early\ngit days unnecessarily complicated, when we don\u0027t have a lot of good\ninfrastructure for it.\n\nLet it rip!\n"
    }
  ]
}