)]}'
{
  "commit": "3d733633a633065729c9e4e254b2e5442c00ef7e",
  "tree": "8b52ba468f275f86221ddb77c29306a2405844fc",
  "parents": [
    "2c463e95480829a2fe8f386589516e13b1289db6"
  ],
  "author": {
    "name": "Dave Hansen",
    "email": "haveblue@us.ibm.com",
    "time": "Fri Feb 15 14:37:59 2008 -0800"
  },
  "committer": {
    "name": "Al Viro",
    "email": "viro@zeniv.linux.org.uk",
    "time": "Sat Apr 19 00:29:27 2008 -0400"
  },
  "message": "[PATCH] r/o bind mounts: track numbers of writers to mounts\n\nThis is the real meat of the entire series.  It actually\nimplements the tracking of the number of writers to a mount.\nHowever, it causes scalability problems because there can be\nhundreds of cpus doing open()/close() on files on the same mnt at\nthe same time.  Even an atomic_t in the mnt has massive scalaing\nproblems because the cacheline gets so terribly contended.\n\nThis uses a statically-allocated percpu variable.  All want/drop\noperations are local to a cpu as long that cpu operates on the same\nmount, and there are no writer count imbalances.  Writer count\nimbalances happen when a write is taken on one cpu, and released\non another, like when an open/close pair is performed on two\n\nUpon a remount,ro request, all of the data from the percpu\nvariables is collected (expensive, but very rare) and we determine\nif there are any outstanding writers to the mount.\n\nI\u0027ve written a little benchmark to sit in a loop for a couple of\nseconds in several cpus in parallel doing open/write/close loops.\n\nhttp://sr71.net/~dave/linux/openbench.c\n\nThe code in here is a a worst-possible case for this patch.  It\ndoes opens on a _pair_ of files in two different mounts in parallel.\nThis should cause my code to lose its \"operate on the same mount\"\noptimization completely.  This worst-case scenario causes a 3%\ndegredation in the benchmark.\n\nI could probably get rid of even this 3%, but it would be more\ncomplex than what I have here, and I think this is getting into\nacceptable territory.  In practice, I expect writing more than 3\nbytes to a file, as well as disk I/O to mask any effects that this\nhas.\n\n(To get rid of that 3%, we could have an #defined number of mounts\nin the percpu variable.  So, instead of a CPU getting operate only\non percpu data when it accesses only one mount, it could stay on\npercpu data when it only accesses N or fewer mounts.)\n\n[AV] merged fix for __clear_mnt_mount() stepping on freed vfsmount\n\nAcked-by: Al Viro \u003cviro@ZenIV.linux.org.uk\u003e\nSigned-off-by: Christoph Hellwig \u003chch@infradead.org\u003e\nSigned-off-by: Dave Hansen \u003chaveblue@us.ibm.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Al Viro \u003cviro@zeniv.linux.org.uk\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "066b393578c1d8ed5bd93a4a366b563d9150fdfa",
      "old_mode": 33188,
      "old_path": "fs/namespace.c",
      "new_id": "e3ce18d91aad69dd2244c779dee5bc64570565c6",
      "new_mode": 33188,
      "new_path": "fs/namespace.c"
    },
    {
      "type": "modify",
      "old_id": "2eecd2c8c760fbfde8225d756d200c01a2569c76",
      "old_mode": 33188,
      "old_path": "include/linux/mount.h",
      "new_id": "8c8e94369ac8ba096d67c2cc1d85ec97127b6956",
      "new_mode": 33188,
      "new_path": "include/linux/mount.h"
    }
  ]
}