)]}'
{
  "log": [
    {
      "commit": "f4ed0deae8983591264d0e194e168ef65f4775f5",
      "tree": "6d25ff09060a69530b1ba0711d20e978edfda92e",
      "parents": [
        "53c78dd1718b99dc365ff8a2244d7d4504b070a5"
      ],
      "author": {
        "name": "Paul Jackson",
        "email": "pj@sgi.com",
        "time": "Mon May 12 14:02:29 2008 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Tue May 13 08:02:25 2008 -0700"
      },
      "message": "cpumask: remove bitmap_scnprintf_len and cpumask_scnprintf_len\n\nThey aren\u0027t used.  They were briefly used as part of some other patches to\nprovide an alternative format for displaying some /proc and /sys cpumasks.\nThey probably should have been removed when those other patches were dropped,\nin favor of a different solution.\n\nSigned-off-by: Paul Jackson \u003cpj@sgi.com\u003e\nCc: \"Mike Travis\" \u003ctravis@sgi.com\u003e\nCc: \"Bert Wesarg\" \u003cbert.wesarg@googlemail.com\u003e\nCc: Alexey Dobriyan \u003cadobriyan@gmail.com\u003e\nCc: WANG Cong \u003cxiyou.wangcong@gmail.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "7ea931c9fc80c4d0a4306c30ec92eb0f1d922a0b",
      "tree": "4f2c85d658c75e8679e01943e3e95866b3729b54",
      "parents": [
        "f5b087b52f1710eb0bf15a2d2b030c51a6a1ca9e"
      ],
      "author": {
        "name": "Paul Jackson",
        "email": "pj@sgi.com",
        "time": "Mon Apr 28 02:12:29 2008 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Mon Apr 28 08:58:19 2008 -0700"
      },
      "message": "mempolicy: add bitmap_onto() and bitmap_fold() operations\n\nThe following adds two more bitmap operators, bitmap_onto() and bitmap_fold(),\nwith the usual cpumask and nodemask wrappers.\n\nThe bitmap_onto() operator computes one bitmap relative to another.  If the\nn-th bit in the origin mask is set, then the m-th bit of the destination mask\nwill be set, where m is the position of the n-th set bit in the relative mask.\n\nThe bitmap_fold() operator folds a bitmap into a second that has bit m set iff\nthe input bitmap has some bit n set, where m \u003d\u003d n mod sz, for the specified sz\nvalue.\n\nThere are two substantive changes between this patch and its\npredecessor bitmap_relative:\n 1) Renamed bitmap_relative() to be bitmap_onto().\n 2) Added bitmap_fold().\n\nThe essential motivation for bitmap_onto() is to provide a mechanism for\nconverting a cpuset-relative CPU or Node mask to an absolute mask.  Cpuset\nrelative masks are written as if the current task were in a cpuset whose CPUs\nor Nodes were just the consecutive ones numbered 0..N-1, for some N.  The\nbitmap_onto() operator is provided in anticipation of adding support for the\nfirst such cpuset relative mask, by the mbind() and set_mempolicy() system\ncalls, using a planned flag of MPOL_F_RELATIVE_NODES.  These bitmap operators\n(and their nodemask wrappers, in particular) will be used in code that\nconverts the user specified cpuset relative memory policy to a specific system\nnode numbered policy, given the current mems_allowed of the tasks cpuset.\n\nSuch cpuset relative mempolicies will address two deficiencies\nof the existing interface between cpusets and mempolicies:\n 1) A task cannot at present reliably establish a cpuset\n    relative mempolicy because there is an essential race\n    condition, in that the tasks cpuset may be changed in\n    between the time the task can query its cpuset placement,\n    and the time the task can issue the applicable mbind or\n    set_memplicy system call.\n 2) A task cannot at present establish what cpuset relative\n    mempolicy it would like to have, if it is in a smaller\n    cpuset than it might have mempolicy preferences for,\n    because the existing interface only allows specifying\n    mempolicies for nodes currently allowed by the cpuset.\n\nCpuset relative mempolicies are useful for tasks that don\u0027t distinguish\nparticularly between one CPU or Node and another, but only between how many of\neach are allowed, and the proper placement of threads and memory pages on the\nvarious CPUs and Nodes available.\n\nThe motivation for the added bitmap_fold() can be seen in the following\nexample.\n\nLet\u0027s say an application has specified some mempolicies that presume 16 memory\nnodes, including say a mempolicy that specified MPOL_F_RELATIVE_NODES (cpuset\nrelative) nodes 12-15.  Then lets say that application is crammed into a\ncpuset that only has 8 memory nodes, 0-7.  If one just uses bitmap_onto(),\nthis mempolicy, mapped to that cpuset, would ignore the requested relative\nnodes above 7, leaving it empty of nodes.  That\u0027s not good; better to fold the\nhigher nodes down, so that some nodes are included in the resulting mapped\nmempolicy.  In this case, the mempolicy nodes 12-15 are taken modulo 8 (the\nweight of the mems_allowed of the confining cpuset), resulting in a mempolicy\nspecifying nodes 4-7.\n\nSigned-off-by: Paul Jackson \u003cpj@sgi.com\u003e\nSigned-off-by: David Rientjes \u003crientjes@google.com\u003e\nCc: Christoph Lameter \u003cclameter@sgi.com\u003e\nCc: Andi Kleen \u003cak@suse.de\u003e\nCc: Mel Gorman \u003cmel@csn.ul.ie\u003e\nCc: Lee Schermerhorn \u003clee.schermerhorn@hp.com\u003e\nCc: \u003ckosaki.motohiro@jp.fujitsu.com\u003e\nCc: \u003cray-lk@madrabbit.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "30ca60c15a725f655e5d3f14e0238a066bc5aeb7",
      "tree": "96d36a2cf12e7a964ce4cd0c49d30b2d40f94b52",
      "parents": [
        "9f0e738f492522a2f70ad9a2a0287e4e966c633a"
      ],
      "author": {
        "name": "Mike Travis",
        "email": "travis@sgi.com",
        "time": "Tue Mar 25 15:06:55 2008 -0700"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Sat Apr 19 19:44:58 2008 +0200"
      },
      "message": "cpumask: add cpumask_scnprintf_len function\n\nAdd a new function cpumask_scnprintf_len() to return the number of\ncharacters needed to display \"len\" cpumask bits.  The current method\nof allocating NR_CPUS bytes is incorrect as what\u0027s really needed is\n9 characters per 32-bit word of cpumask bits (8 hex digits plus the\nseperator [\u0027,\u0027] or the terminating NULL.)  This function provides the\ncaller the means to allocate the correct string length.\n\nCc: Paul Jackson \u003cpj@sgi.com\u003e\nSigned-off-by: Mike Travis \u003ctravis@sgi.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "14ed9d23aa9acd79210a92ac561a728b42a8e281",
      "tree": "2a8aca939e4f4376b26485b518d55d152dd45e48",
      "parents": [
        "1cafc30f43696e8b1b6f7ef4fed354cb3e3af2e6"
      ],
      "author": {
        "name": "Jiri Slaby",
        "email": "jirislaby@gmail.com",
        "time": "Thu Oct 18 23:40:37 2007 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Fri Oct 19 11:53:42 2007 -0700"
      },
      "message": "remove BITS_TO_TYPE macro\n\nremove BITS_TO_TYPE macro\n\nI realized, that it is actually the same as DIV_ROUND_UP, use it instead.\n\n[akpm@linux-foundation.org: build fix]\nSigned-off-by: Jiri Slaby \u003cjirislaby@gmail.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "01a3ee2b203e511e20f98b85a9172fd32c53e87c",
      "tree": "0dd90d81dc86f231828af23bdb97522405b06cab",
      "parents": [
        "39484e53bb00f55b6303a908070db133608ef2a5"
      ],
      "author": {
        "name": "Reinette Chatre",
        "email": "reinette.chatre@linux.intel.com",
        "time": "Wed Oct 11 01:21:55 2006 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Wed Oct 11 11:14:22 2006 -0700"
      },
      "message": "[PATCH] bitmap: parse input from kernel and user buffers\n\nlib/bitmap.c:bitmap_parse() is a library function that received as input a\nuser buffer.  This seemed to have originated from the way the write_proc\nfunction of the /proc filesystem operates.\n\nThis has been reworked to not use kmalloc and eliminates a lot of\nget_user() overhead by performing one access_ok before using __get_user().\n\nWe need to test if we are in kernel or user space (is_user) and access the\nbuffer differently.  We cannot use __get_user() to access kernel addresses\nin all cases, for example in architectures with separate address space for\nkernel and user.\n\nThis function will be useful for other uses as well; for example, taking\ninput for /sysfs instead of /proc, so it was changed to accept kernel\nbuffers.  We have this use for the Linux UWB project, as part as the\nupcoming bandwidth allocator code.\n\nOnly a few routines used this function and they were changed too.\n\nSigned-off-by: Reinette Chatre \u003creinette.chatre@linux.intel.com\u003e\nSigned-off-by: Inaky Perez-Gonzalez \u003cinaky@linux.intel.com\u003e\nCc: Paul Jackson \u003cpj@sgi.com\u003e\nCc: Joe Korty \u003cjoe.korty@ccur.com\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "08cd36570e47176c7b6bd3e80125aa46c4638097",
      "tree": "02c9cb3be4a2b520772e9b66bb57901401dd2666",
      "parents": [
        "5282aab87a8be3f5e6c36a4c2ee4b71852def1bb"
      ],
      "author": {
        "name": "Andi Kleen",
        "email": "ak@suse.de",
        "time": "Mon Jun 26 13:57:10 2006 +0200"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Mon Jun 26 10:48:16 2006 -0700"
      },
      "message": "[PATCH] x86_64: Optimize bitmap_weight for small bitmaps\n\nUse inline code bitmaps \u003c\u003d BITS_PER_LONG in bitmap_weight. This\ngives _much_ better code.\n\nSigned-off-by: Andi Kleen \u003cak@suse.de\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "87e24802586333fa861861f6493c76039872755b",
      "tree": "631a252da4716798027cd96b4529351e601c50c6",
      "parents": [
        "f993b3bf80b23d329951fe0fc5ba3647d5d912e9"
      ],
      "author": {
        "name": "Paul Jackson",
        "email": "pj@sgi.com",
        "time": "Fri Mar 24 03:15:44 2006 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Fri Mar 24 07:33:20 2006 -0800"
      },
      "message": "[PATCH] bitmap: region cleanup\n\nPaul Mundt \u003clethal@linux-sh.org\u003e says:\n\nThis patch set implements a number of patches to clean up and restructure the\nbitmap region code, in addition to extending the interface to support\nmultiword spanning allocations.\n\nThe current implementation (before this patch set) is limited by only being\nable to allocate pages \u003c\u003d BITS_PER_LONG, as noted by the strategically\npositioned BUG_ON() at lib/bitmap.c:752:\n\n        /* We don\u0027t do regions of pages \u003e BITS_PER_LONG.  The\n\t * algorithm would be a simple look for multiple zeros in the\n\t * array, but there\u0027s no driver today that needs this.  If you\n\t * trip this BUG(), you get to code it... */\n        BUG_ON(pages \u003e BITS_PER_LONG);\n\nAs I seem to have been the first person to trigger this, the result ends up\nbeing the following patch set with the help of Paul Jackson.\n\nThe final patch in the series eliminates quite a bit of code duplication, so\nthe bitmap code size ends up being smaller than the current implementation as\nan added bonus.\n\nAfter these are applied, it should already be possible to do multiword\nallocations with dma_alloc_coherent() out of ranges established by\ndma_declare_coherent_memory() on x86 without having to change any of the code,\nand the SH store queue API will follow up on this as the other user that needs\nsupport for this.\n\nThis patch:\n\nSome code cleanup on the lib/bitmap.c bitmap_*_region() routines:\n\n * spacing\n * variable names\n * comments\n\nHas no change to code function.\n\nSigned-off-by: Paul Mundt \u003clethal@linux-sh.org\u003e\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": "fb5eeeee44edb248b4837416966f19731f497f79",
      "tree": "f947a4dcf103f55d526bb5c71f69b657d8f22e61",
      "parents": [
        "28a42b9ea7e42e1efb02cc2dcacba0b6af234e1b"
      ],
      "author": {
        "name": "Paul Jackson",
        "email": "pj@sgi.com",
        "time": "Sun Oct 30 15:02:33 2005 -0800"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sun Oct 30 17:37:21 2005 -0800"
      },
      "message": "[PATCH] cpusets: bitmap and mask remap operators\n\nIn the forthcoming task migration support, a key calculation will be\nmapping cpu and node numbers from the old set to the new set while\npreserving cpuset-relative offset.\n\nFor example, if a task and its pages on nodes 8-11 are being migrated to\nnodes 24-27, then pages on node 9 (the 2nd node in the old set) should be\nmoved to node 25 (the 2nd node in the new set.)\n\nAs with other bitmap operations, the proper way to code this is to provide\nthe underlying calculation in lib/bitmap.c, and then to provide the usual\ncpumask and nodemask wrappers.\n\nThis patch provides that.  These operations are termed \u0027remap\u0027 operations.\nBoth remapping a single bit and a set of bits is supported.\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": "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"
    }
  ]
}