)]}'
{
  "log": [
    {
      "commit": "68860ec10bcc07ab4f89f9d940e3b77ae5ca13b3",
      "tree": "a411f9623a113d72f23da38cf2de51f66c177873",
      "parents": [
        "fb5eeeee44edb248b4837416966f19731f497f79"
      ],
      "author": {
        "name": "Paul Jackson",
        "email": "pj@sgi.com",
        "time": "Sun Oct 30 15:02:36 2005 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Oct 30 17:37:22 2005 -0800"
      },
      "message": "[PATCH] cpusets: automatic numa mempolicy rebinding\n\nThis patch automatically updates a tasks NUMA mempolicy when its cpuset\nmemory placement changes.  It does so within the context of the task,\nwithout any need to support low level external mempolicy manipulation.\n\nIf a system is not using cpusets, or if running on a system with just the\nroot (all-encompassing) cpuset, then this remap is a no-op.  Only when a\ntask is moved between cpusets, or a cpusets memory placement is changed\ndoes the following apply.  Otherwise, the main routine below,\nrebind_policy() is not even called.\n\nWhen mixing cpusets, scheduler affinity, and NUMA mempolicies, the\nessential role of cpusets is to place jobs (several related tasks) on a set\nof CPUs and Memory Nodes, the essential role of sched_setaffinity is to\nmanage a jobs processor placement within its allowed cpuset, and the\nessential role of NUMA mempolicy (mbind, set_mempolicy) is to manage a jobs\nmemory placement within its allowed cpuset.\n\nHowever, CPU affinity and NUMA memory placement are managed within the\nkernel using absolute system wide numbering, not cpuset relative numbering.\n\nThis is ok until a job is migrated to a different cpuset, or what\u0027s the\nsame, a jobs cpuset is moved to different CPUs and Memory Nodes.\n\nThen the CPU affinity and NUMA memory placement of the tasks in the job\nneed to be updated, to preserve their cpuset-relative position.  This can\nbe done for CPU affinity using sched_setaffinity() from user code, as one\ntask can modify anothers CPU affinity.  This cannot be done from an\nexternal task for NUMA memory placement, as that can only be modified in\nthe context of the task using it.\n\nHowever, it easy enough to remap a tasks NUMA mempolicy automatically when\na task is migrated, using the existing cpuset mechanism to trigger a\nrefresh of a tasks memory placement after its cpuset has changed.  All that\nis needed is the old and new nodemask, and notice to the task that it needs\nto rebind its mempolicy.  The tasks mems_allowed has the old mask, the\ntasks cpuset has the new mask, and the existing\ncpuset_update_current_mems_allowed() mechanism provides the notice.  The\nbitmap/cpumask/nodemask remap operators provide the cpuset relative\ncalculations.\n\nThis patch leaves open a couple of issues:\n\n 1) Updating vma and shmfs/tmpfs/hugetlbfs memory policies:\n\n    These mempolicies may reference nodes outside of those allowed to\n    the current task by its cpuset.  Tasks are migrated as part of jobs,\n    which reside on what might be several cpusets in a subtree.  When such\n    a job is migrated, all NUMA memory policy references to nodes within\n    that cpuset subtree should be translated, and references to any nodes\n    outside that subtree should be left untouched.  A future patch will\n    provide the cpuset mechanism needed to mark such subtrees.  With that\n    patch, we will be able to correctly migrate these other memory policies\n    across a job migration.\n\n 2) Updating cpuset, affinity and memory policies in user space:\n\n    This is harder.  Any placement state stored in user space using\n    system-wide numbering will be invalidated across a migration.  More\n    work will be required to provide user code with a migration-safe means\n    to manage its cpuset relative placement, while preserving the current\n    API\u0027s that pass system wide numbers, not cpuset relative numbers across\n    the kernel-user boundary.\n\nSigned-off-by: Paul Jackson \u003cpj@sgi.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "b8072f099b7829a6ff3eba618e1d079a81f753f8",
      "tree": "80bf801b68ecf5f29a61f0f4fd5976b4daa91c6a",
      "parents": [
        "f412ac08c9861b4791af0145934c22f1458686da"
      ],
      "author": {
        "name": "Hugh Dickins",
        "email": "hugh@veritas.com",
        "time": "Sat Oct 29 18:16:41 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sat Oct 29 21:40:42 2005 -0700"
      },
      "message": "[PATCH] mm: update comments to pte lock\n\nUpdated several references to page_table_lock in common code comments.\n\nSigned-off-by: Hugh Dickins \u003chugh@veritas.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "dfcd3c0dc426bb75770c34b40e14f2da8845ea62",
      "tree": "bd7e9f8463a18025c4775c6cdf22abbbd4236b64",
      "parents": [
        "e46a5e28c201f703c18b47b108bfddec44f897c4"
      ],
      "author": {
        "name": "Andi Kleen",
        "email": "ak@suse.de",
        "time": "Sat Oct 29 18:15:48 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sat Oct 29 21:40:35 2005 -0700"
      },
      "message": "[PATCH] Convert mempolicies to nodemask_t\n\nThe NUMA policy code predated nodemask_t so it used open coded bitmaps.\nConvert everything to nodemask_t.  Big patch, but shouldn\u0027t have any actual\nbehaviour changes (except I removed one unnecessary check against\nnode_online_map and one unnecessary BUG_ON)\n\nSigned-off-by: \"Andi Kleen\" \u003cak@suse.de\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "d42c69972b853fd33a26c8c7405624be41a22136",
      "tree": "2ac805f0da1279492939f8627103f5f9a040034c",
      "parents": [
        "56d8456b06ad1316bff3c75caed5e06e786f20d8"
      ],
      "author": {
        "name": "Andi Kleen",
        "email": "ak@suse.de",
        "time": "Wed Jul 06 19:56:03 2005 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@suse.de",
        "time": "Thu Sep 08 14:57:23 2005 -0700"
      },
      "message": "[PATCH] PCI: Run PCI driver initialization on local node\n\nRun PCI driver initialization on local node\n\nInstead of adding messy kmalloc_node()s everywhere run the\nPCI driver probe on the node local to the device.\n\nThis would not have helped for IDE, but should for\nother more clean drivers that do more initialization in probe().\nIt won\u0027t help for drivers that do most of the work\non first open (like many network drivers)\n\nSigned-off-by: Andi Kleen \u003cak@suse.de\u003e\nSigned-off-by: Greg Kroah-Hartman \u003cgregkh@suse.de\u003e\n"
    },
    {
      "commit": "6e21c8f145f5052c1c2fb4a4b41bee01c848159b",
      "tree": "0b956cfbd67636c19be79fc0cbe0a5ed89fb6b9a",
      "parents": [
        "839b9685e80592809d6dfdd865986cd1b5ddc2fb"
      ],
      "author": {
        "name": "Christoph Lameter",
        "email": "clameter@engr.sgi.com",
        "time": "Sat Sep 03 15:54:45 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@evo.osdl.org",
        "time": "Mon Sep 05 00:05:43 2005 -0700"
      },
      "message": "[PATCH] /proc/\u003cpid\u003e/numa_maps to show on which nodes pages reside\n\nThis patch was recently discussed on linux-mm:\nhttp://marc.theaimsgroup.com/?t\u003d112085728500002\u0026r\u003d1\u0026w\u003d2\n\nI inherited a large code base from Ray for page migration.  There was a\nsmall patch in there that I find to be very useful since it allows the\ndisplay of the locality of the pages in use by a process.  I reworked that\npatch and came up with a /proc/\u003cpid\u003e/numa_maps that gives more information\nabout the vma\u0027s of a process.  numa_maps is indexes by the start address\nfound in /proc/\u003cpid\u003e/maps.  F.e.  with this patch you can see the page use\nof the \"getty\" process:\n\nmargin:/proc/12008 # cat maps\n00000000-00004000 r--p 00000000 00:00 0\n2000000000000000-200000000002c000 r-xp 00000000 08:04 516                /lib/ld-2.3.3.so\n2000000000038000-2000000000040000 rw-p 00028000 08:04 516                /lib/ld-2.3.3.so\n2000000000040000-2000000000044000 rw-p 2000000000040000 00:00 0\n2000000000058000-2000000000260000 r-xp 00000000 08:04 54707842           /lib/tls/libc.so.6.1\n2000000000260000-2000000000268000 ---p 00208000 08:04 54707842           /lib/tls/libc.so.6.1\n2000000000268000-2000000000274000 rw-p 00200000 08:04 54707842           /lib/tls/libc.so.6.1\n2000000000274000-2000000000280000 rw-p 2000000000274000 00:00 0\n2000000000280000-20000000002b4000 r--p 00000000 08:04 9126923            /usr/lib/locale/en_US.utf8/LC_CTYPE\n2000000000300000-2000000000308000 r--s 00000000 08:04 60071467           /usr/lib/gconv/gconv-modules.cache\n2000000000318000-2000000000328000 rw-p 2000000000318000 00:00 0\n4000000000000000-4000000000008000 r-xp 00000000 08:04 29576399           /sbin/mingetty\n6000000000004000-6000000000008000 rw-p 00004000 08:04 29576399           /sbin/mingetty\n6000000000008000-600000000002c000 rw-p 6000000000008000 00:00 0          [heap]\n60000fff7fffc000-60000fff80000000 rw-p 60000fff7fffc000 00:00 0\n60000ffffff44000-60000ffffff98000 rw-p 60000ffffff44000 00:00 0          [stack]\na000000000000000-a000000000020000 ---p 00000000 00:00 0                  [vdso]\n\ncat numa_maps\n2000000000000000 default MaxRef\u003d43 Pages\u003d11 Mapped\u003d11 N0\u003d4 N1\u003d3 N2\u003d2 N3\u003d2\n2000000000038000 default MaxRef\u003d1 Pages\u003d2 Mapped\u003d2 Anon\u003d2 N0\u003d2\n2000000000040000 default MaxRef\u003d1 Pages\u003d1 Mapped\u003d1 Anon\u003d1 N0\u003d1\n2000000000058000 default MaxRef\u003d43 Pages\u003d61 Mapped\u003d61 N0\u003d14 N1\u003d15 N2\u003d16 N3\u003d16\n2000000000268000 default MaxRef\u003d1 Pages\u003d2 Mapped\u003d2 Anon\u003d2 N0\u003d2\n2000000000274000 default MaxRef\u003d1 Pages\u003d3 Mapped\u003d3 Anon\u003d3 N0\u003d3\n2000000000280000 default MaxRef\u003d8 Pages\u003d3 Mapped\u003d3 N0\u003d3\n2000000000300000 default MaxRef\u003d8 Pages\u003d2 Mapped\u003d2 N0\u003d2\n2000000000318000 default MaxRef\u003d1 Pages\u003d1 Mapped\u003d1 Anon\u003d1 N2\u003d1\n4000000000000000 default MaxRef\u003d6 Pages\u003d2 Mapped\u003d2 N1\u003d2\n6000000000004000 default MaxRef\u003d1 Pages\u003d1 Mapped\u003d1 Anon\u003d1 N0\u003d1\n6000000000008000 default MaxRef\u003d1 Pages\u003d1 Mapped\u003d1 Anon\u003d1 N0\u003d1\n60000fff7fffc000 default MaxRef\u003d1 Pages\u003d1 Mapped\u003d1 Anon\u003d1 N0\u003d1\n60000ffffff44000 default MaxRef\u003d1 Pages\u003d1 Mapped\u003d1 Anon\u003d1 N0\u003d1\n\ngetty uses ld.so.  The first vma is the code segment which is used by 43\nother processes and the pages are evenly distributed over the 4 nodes.\n\nThe second vma is the process specific data portion for ld.so.  This is\nonly one page.\n\nThe display format is:\n\n\u003cstartaddress\u003e\t Links to information in /proc/\u003cpid\u003e/map\n\u003cmemory policy\u003e  This can be \"default\" \"interleave\u003d{}\", \"prefer\u003d\u003cnode\u003e\" or \"bind\u003d{\u003czones\u003e}\"\nMaxRef\u003d\t\t\u003cmaximum reference to a page in this vma\u003e\nPages\u003d\t\t\u003cNr of pages in use\u003e\nMapped\u003d\t\t\u003cNr of pages with mapcount \u003e\nAnon\u003d\t\t\u003cnr of anonymous pages\u003e\nNx\u003d\t\t\u003cNr of pages on Node x\u003e\n\nThe content of the proc-file is self-evident.  If this would be tied into\nthe sparsemem system then the contents of this file would not be too\nuseful.\n\nSigned-off-by: Christoph Lameter \u003cclameter@sgi.com\u003e\nCc: Hugh Dickins \u003chugh@veritas.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"
    }
  ]
}