)]}'
{
  "commit": "73ff5fc0a86b28b77e02a6963b388d1dbfa0a263",
  "tree": "7b84f738078e6b96f6b35805c8b6c4fa699968ed",
  "parents": [
    "415103f9932d45f7927f4b17e3a9a13834cdb9a1"
  ],
  "author": {
    "name": "Eric Paris",
    "email": "eparis@redhat.com",
    "time": "Tue Dec 07 16:17:28 2010 -0500"
  },
  "committer": {
    "name": "Eric Paris",
    "email": "eparis@redhat.com",
    "time": "Tue Dec 07 16:44:01 2010 -0500"
  },
  "message": "selinux: cache sidtab_context_to_sid results\n\nsidtab_context_to_sid takes up a large share of time when creating large\nnumbers of new inodes (~30-40% in oprofile runs).  This patch implements a\ncache of 3 entries which is checked before we do a full context_to_sid lookup.\nOn one system this showed over a x3 improvement in the number of inodes that\ncould be created per second and around a 20% improvement on another system.\n\nAny time we look up the same context string sucessivly (imagine ls -lZ) we\nshould hit this cache hot.  A cache miss should have a relatively minor affect\non performance next to doing the full table search.\n\nAll operations on the cache are done COMPLETELY lockless.  We know that all\nstruct sidtab_node objects created will never be deleted until a new policy is\nloaded thus we never have to worry about a pointer being dereferenced.  Since\nwe also know that pointer assignment is atomic we know that the cache will\nalways have valid pointers.  Given this information we implement a FIFO cache\nin an array of 3 pointers.  Every result (whether a cache hit or table lookup)\nwill be places in the 0 spot of the cache and the rest of the entries moved\ndown one spot.  The 3rd entry will be lost.\n\nRaces are possible and are even likely to happen.  Lets assume that 4 tasks\nare hitting sidtab_context_to_sid.  The first task checks against the first\nentry in the cache and it is a miss.  Now lets assume a second task updates\nthe cache with a new entry.  This will push the first entry back to the second\nspot.  Now the first task might check against the second entry (which it\nalready checked) and will miss again.  Now say some third task updates the\ncache and push the second entry to the third spot.  The first task my check\nthe third entry (for the third time!) and again have a miss.  At which point\nit will just do a full table lookup.  No big deal!\n\nSigned-off-by: Eric Paris \u003ceparis@redhat.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e817989764cd48dd4061bc49c30c6cb8da357474",
      "old_mode": 33188,
      "old_path": "security/selinux/ss/sidtab.c",
      "new_id": "5840a35155fc3d613ec10abceee8420c1b40073f",
      "new_mode": 33188,
      "new_path": "security/selinux/ss/sidtab.c"
    },
    {
      "type": "modify",
      "old_id": "64ea5b1cdea4775908a871e9c728aed6be5e3e30",
      "old_mode": 33188,
      "old_path": "security/selinux/ss/sidtab.h",
      "new_id": "84dc154d9389db3b6353443e7c6d3c1997e08a76",
      "new_mode": 33188,
      "new_path": "security/selinux/ss/sidtab.h"
    }
  ]
}