)]}'
{
  "log": [
    {
      "commit": "fb1c8f93d869b34cacb8b8932e2b83d96a19d720",
      "tree": "a006d078aa02e421a7dc4793c335308204859d36",
      "parents": [
        "4327edf6b8a7ac7dce144313947995538842d8fd"
      ],
      "author": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Sat Sep 10 00:25:56 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@g5.osdl.org",
        "time": "Sat Sep 10 10:06:21 2005 -0700"
      },
      "message": "[PATCH] spinlock consolidation\n\nThis patch (written by me and also containing many suggestions of Arjan van\nde Ven) does a major cleanup of the spinlock code.  It does the following\nthings:\n\n - consolidates and enhances the spinlock/rwlock debugging code\n\n - simplifies the asm/spinlock.h files\n\n - encapsulates the raw spinlock type and moves generic spinlock\n   features (such as -\u003ebreak_lock) into the generic code.\n\n - cleans up the spinlock code hierarchy to get rid of the spaghetti.\n\nMost notably there\u0027s now only a single variant of the debugging code,\nlocated in lib/spinlock_debug.c.  (previously we had one SMP debugging\nvariant per architecture, plus a separate generic one for UP builds)\n\nAlso, i\u0027ve enhanced the rwlock debugging facility, it will now track\nwrite-owners.  There is new spinlock-owner/CPU-tracking on SMP builds too.\nAll locks have lockup detection now, which will work for both soft and hard\nspin/rwlock lockups.\n\nThe arch-level include files now only contain the minimally necessary\nsubset of the spinlock code - all the rest that can be generalized now\nlives in the generic headers:\n\n include/asm-i386/spinlock_types.h       |   16\n include/asm-x86_64/spinlock_types.h     |   16\n\nI have also split up the various spinlock variants into separate files,\nmaking it easier to see which does what. The new layout is:\n\n   SMP                         |  UP\n   ----------------------------|-----------------------------------\n   asm/spinlock_types_smp.h    |  linux/spinlock_types_up.h\n   linux/spinlock_types.h      |  linux/spinlock_types.h\n   asm/spinlock_smp.h          |  linux/spinlock_up.h\n   linux/spinlock_api_smp.h    |  linux/spinlock_api_up.h\n   linux/spinlock.h            |  linux/spinlock.h\n\n/*\n * here\u0027s the role of the various spinlock/rwlock related include files:\n *\n * on SMP builds:\n *\n *  asm/spinlock_types.h: contains the raw_spinlock_t/raw_rwlock_t and the\n *                        initializers\n *\n *  linux/spinlock_types.h:\n *                        defines the generic type and initializers\n *\n *  asm/spinlock.h:       contains the __raw_spin_*()/etc. lowlevel\n *                        implementations, mostly inline assembly code\n *\n *   (also included on UP-debug builds:)\n *\n *  linux/spinlock_api_smp.h:\n *                        contains the prototypes for the _spin_*() APIs.\n *\n *  linux/spinlock.h:     builds the final spin_*() APIs.\n *\n * on UP builds:\n *\n *  linux/spinlock_type_up.h:\n *                        contains the generic, simplified UP spinlock type.\n *                        (which is an empty structure on non-debug builds)\n *\n *  linux/spinlock_types.h:\n *                        defines the generic type and initializers\n *\n *  linux/spinlock_up.h:\n *                        contains the __raw_spin_*()/etc. version of UP\n *                        builds. (which are NOPs on non-debug, non-preempt\n *                        builds)\n *\n *   (included on UP-non-debug builds:)\n *\n *  linux/spinlock_api_up.h:\n *                        builds the _spin_*() APIs.\n *\n *  linux/spinlock.h:     builds the final spin_*() APIs.\n */\n\nAll SMP and UP architectures are converted by this patch.\n\narm, i386, ia64, ppc, ppc64, s390/s390x, x64 was build-tested via\ncrosscompilers.  m32r, mips, sh, sparc, have not been tested yet, but should\nbe mostly fine.\n\nFrom: Grant Grundler \u003cgrundler@parisc-linux.org\u003e\n\n  Booted and lightly tested on a500-44 (64-bit, SMP kernel, dual CPU).\n  Builds 32-bit SMP kernel (not booted or tested).  I did not try to build\n  non-SMP kernels.  That should be trivial to fix up later if necessary.\n\n  I converted bit ops atomic_hash lock to raw_spinlock_t.  Doing so avoids\n  some ugly nesting of linux/*.h and asm/*.h files.  Those particular locks\n  are well tested and contained entirely inside arch specific code.  I do NOT\n  expect any new issues to arise with them.\n\n If someone does ever need to use debug/metrics with them, then they will\n  need to unravel this hairball between spinlocks, atomic ops, and bit ops\n  that exist only because parisc has exactly one atomic instruction: LDCW\n  (load and clear word).\n\nFrom: \"Luck, Tony\" \u003ctony.luck@intel.com\u003e\n\n   ia64 fix\n\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\nSigned-off-by: Arjan van de Ven \u003carjanv@infradead.org\u003e\nSigned-off-by: Grant Grundler \u003cgrundler@parisc-linux.org\u003e\nCc: Matthew Wilcox \u003cwilly@debian.org\u003e\nSigned-off-by: Hirokazu Takata \u003ctakata@linux-m32r.org\u003e\nSigned-off-by: Mikael Pettersson \u003cmikpe@csd.uu.se\u003e\nSigned-off-by: Benoit Boissinot \u003cbenoit.boissinot@ens-lyon.org\u003e\nSigned-off-by: Andrew Morton \u003cakpm@osdl.org\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@osdl.org\u003e\n"
    },
    {
      "commit": "d637413f3f05b41f678f8004225b33b62274183f",
      "tree": "08a2240395ffef19a3d61ea7de4f55704f8046fe",
      "parents": [
        "d59dd4620fb8d6422555a9e2b82a707718e68327"
      ],
      "author": {
        "name": "Jake Moilanen",
        "email": "moilanen@austin.ibm.com",
        "time": "Sun May 01 08:58:47 2005 -0700"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@ppc970.osdl.org",
        "time": "Sun May 01 08:58:47 2005 -0700"
      },
      "message": "[PATCH] ppc64: reverse prediction on spinlock busy loop code\n\nOn our raw spinlocks, we currently have an attempt at the lock, and if we do\nnot get it we enter a spin loop.  This spinloop will likely continue for\nawhile, and we pridict likely.\n\nShouldn\u0027t we predict that we will get out of the loop so our next instructions\nare already prefetched.  Even when we miss because the lock is still held, it\nwon\u0027t matter since we are waiting anyways.\n\nI did a couple quick benchmarks, but the results are inconclusive.\n\n\t16-way 690 running specjbb with original code\n\t# ./specjbb 3000 16 1 1 19 30 120\n\t    ...\n\tValid run, Score is 59282\n\n\t16-way 690 running specjbb with unlikely code\n\t# ./specjbb 3000 16 1 1 19 30 120\n\t    ...\n\tValid run, Score is 59541\n\nI saw a smaller increase on a JS20 (~1.6%)\n\n\tJS20 specjbb w/ original code\n\t# ./specjbb 400 2 1 1 19 30 120\n\t   ...\n\tValid run, Score is 20460\n\n\tJS20 specjbb w/ unlikely code\n\t# ./specjbb 400 2 1 1 19 30 120\n\t   ...\n\tValid run, Score is 20803\n\nAnton said:\n\nMispredicting the spinlock busy loop also means we slow down the rate at which\nwe do the loads which can be good for heavily contended locks.\n\nNote: There are some gcc issues with our default build and branch prediction,\nbut a CONFIG_POWER4_ONLY build should emit them correctly.  I\u0027m working with\nAlan Modra on it now.\n\nSigned-off-by: Jake Moilanen \u003cmoilanen@austin.ibm.com\u003e\nSigned-off-by: Anton Blanchard \u003canton@samba.org\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"
    }
  ]
}
