)]}'
{
  "log": [
    {
      "commit": "133fd9f5cda2d86904126f4b9fa4e8f4330c9569",
      "tree": "0e60bfcec85f123243cf1ffe735264527efd6d0e",
      "parents": [
        "725fe002d315c2501c110b7245d3eb4f4535f4d6"
      ],
      "author": {
        "name": "Denys Vlasenko",
        "email": "vda.linux@googlemail.com",
        "time": "Thu May 31 16:26:08 2012 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@linux-foundation.org",
        "time": "Thu May 31 17:49:27 2012 -0700"
      },
      "message": "vsprintf: further optimize decimal conversion\n\nPrevious code was using optimizations which were developed to work well\neven on narrow-word CPUs (by today\u0027s standards).  But Linux runs only on\n32-bit and wider CPUs.  We can use that.\n\nFirst: using 32x32-\u003e64 multiply and trivial 32-bit shift, we can correctly\ndivide by 10 much larger numbers, and thus we can print groups of 9 digits\ninstead of groups of 5 digits.\n\nNext: there are two algorithms to print larger numbers.  One is generic:\ndivide by 1000000000 and repeatedly print groups of (up to) 9 digits.\nIt\u0027s conceptually simple, but requires an (unsigned long long) /\n1000000000 division.\n\nSecond algorithm splits 64-bit unsigned long long into 16-bit chunks,\nmanipulates them cleverly and generates groups of 4 decimal digits.  It so\nhappens that it does NOT require long long division.\n\nIf long is \u003e 32 bits, division of 64-bit values is relatively easy, and we\nwill use the first algorithm.  If long long is \u003e 64 bits (strange\narchitecture with VERY large long long), second algorithm can\u0027t be used,\nand we again use the first one.\n\nElse (if long is 32 bits and long long is 64 bits) we use second one.\n\nAnd third: there is a simple optimization which takes fast path not only\nfor zero as was done before, but for all one-digit numbers.\n\nIn all tested cases new code is faster than old one, in many cases by 30%,\nin few cases by more than 50% (for example, on x86-32, conversion of\n12345678).  Code growth is ~0 in 32-bit case and ~130 bytes in 64-bit\ncase.\n\nThis patch is based upon an original from Michal Nazarewicz.\n\n[akpm@linux-foundation.org: checkpatch fixes]\nSigned-off-by: Michal Nazarewicz \u003cmina86@mina86.com\u003e\nSigned-off-by: Denys Vlasenko \u003cvda.linux@googlemail.com\u003e\nCc: Douglas W Jones \u003cjones@cs.uiowa.edu\u003e\nSigned-off-by: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "c31ae4bb4a9fa4606a74c0a4fb61b74f804e861e",
      "tree": "7694b1a05bc1ac660ac26eb9997200556ccd3933",
      "parents": [
        "63b852a6b67d0820d388b0ecd0da83ccb4048b8d"
      ],
      "author": {
        "name": "Arnd Bergmann",
        "email": "arnd@arndb.de",
        "time": "Wed May 13 22:56:25 2009 +0000"
      },
      "committer": {
        "name": "Arnd Bergmann",
        "email": "arnd@klappe2.(none)",
        "time": "Thu Jun 11 21:02:14 2009 +0200"
      },
      "message": "asm-generic: introduce asm/bitsperlong.h\n\nThis provides a reliable way for asm-generic/types.h and other\nfiles to find out if it is running on a 32 or 64 bit platform.\n\nWe cannot use CONFIG_64BIT for this in headers that are included\nfrom user space because CONFIG symbols are not available there.\nWe also cannot do it inside of asm/types.h because some headers\nneed the word size but cannot include types.h.\n\nThe solution is to introduce a new header \u003casm/bitsperlong.h\u003e\nthat defines both __BITS_PER_LONG for user space and\nBITS_PER_LONG for usage in the kernel. The asm-generic\nversion falls back to 32 bit unless the architecture overrides\nit, which I did for all 64 bit platforms.\n\nSigned-off-by: Remis Lima Baima \u003cremis.developer@googlemail.com\u003e\nSigned-off-by: Arnd Bergmann \u003carnd@arndb.de\u003e\n"
    }
  ]
}