)]}'
{
  "commit": "8f5be20bf87da7c7c59c5cc84f630a1eca5cc99c",
  "tree": "0fc18e33fa1b43543837e99a0f09c77f686f327b",
  "parents": [
    "a44b56d354b49f9abb184e5a14f71889856283bb"
  ],
  "author": {
    "name": "Ravikiran G Thirumalai",
    "email": "kiran@scalex86.org",
    "time": "Wed Dec 06 20:32:14 2006 -0800"
  },
  "committer": {
    "name": "Linus Torvalds",
    "email": "torvalds@woody.osdl.org",
    "time": "Thu Dec 07 08:39:21 2006 -0800"
  },
  "message": "[PATCH] mm: slab: eliminate lock_cpu_hotplug from slab\n\nHere\u0027s an attempt towards doing away with lock_cpu_hotplug in the slab\nsubsystem.  This approach also fixes a bug which shows up when cpus are\nbeing offlined/onlined and slab caches are being tuned simultaneously.\n\nhttp://marc.theaimsgroup.com/?l\u003dlinux-kernel\u0026m\u003d116098888100481\u0026w\u003d2\n\nThe patch has been stress tested overnight on a 2 socket 4 core AMD box with\nrepeated cpu online and offline, while dbench and kernbench process are\nrunning, and slab caches being tuned at the same time.\nThere were no lockdep warnings either.  (This test on 2,6.18 as 2.6.19-rc\ncrashes at __drain_pages\nhttp://marc.theaimsgroup.com/?l\u003dlinux-kernel\u0026m\u003d116172164217678\u0026w\u003d2 )\n\nThe approach here is to hold cache_chain_mutex from CPU_UP_PREPARE until\nCPU_ONLINE (similar in approach as worqueue_mutex) .  Slab code sensitive\nto cpu_online_map (kmem_cache_create, kmem_cache_destroy, slabinfo_write,\n__cache_shrink) is already serialized with cache_chain_mutex.  (This patch\nlengthens cache_chain_mutex hold time at kmem_cache_destroy to cover this).\n This patch also takes the cache_chain_sem at kmem_cache_shrink to protect\nsanity of cpu_online_map at __cache_shrink, as viewed by slab.\n(kmem_cache_shrink-\u003e__cache_shrink-\u003edrain_cpu_caches).  But, really,\nkmem_cache_shrink is used at just one place in the acpi subsystem!  Do we\nreally need to keep kmem_cache_shrink at all?\n\nAnother note.  Looks like a cpu hotplug event can send  CPU_UP_CANCELED to\na registered subsystem even if the subsystem did not receive CPU_UP_PREPARE.\nThis could be due to a subsystem registered for notification earlier than\nthe current subsystem crapping out with NOTIFY_BAD. Badness can occur with\nin the CPU_UP_CANCELED code path at slab if this happens (The same would\napply for workqueue.c as well).  To overcome this, we might have to use either\na) a per subsystem flag and avoid handling of CPU_UP_CANCELED, or\nb) Use a special notifier events like LOCK_ACQUIRE/RELEASE as Gautham was\n   using in his experiments, or\nc) Do not send CPU_UP_CANCELED to a subsystem which did not receive\n   CPU_UP_PREPARE.\n\nI would prefer c).\n\nSigned-off-by: Ravikiran Thirumalai \u003ckiran@scalex86.org\u003e\nSigned-off-by: Shai Fultheim \u003cshai@scalex86.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ff60a94142f995aceaa5e684cf6ed55c3138189d",
      "old_mode": 33188,
      "old_path": "mm/slab.c",
      "new_id": "3318252f657f30374e2151a77ca97be68f1bdc12",
      "new_mode": 33188,
      "new_path": "mm/slab.c"
    }
  ]
}