)]}'
{
  "log": [
    {
      "commit": "ef631b0ca01655d24e9ca7e199262c4a46416a26",
      "tree": "0ef86d5b97c6e2de500e639ebb92da8f2ec8c863",
      "parents": [
        "27b19565fe4ca5b0e9d2ae98ce4b81ca728bf445"
      ],
      "author": {
        "name": "Paul E. McKenney",
        "email": "paulmck@linux.vnet.ibm.com",
        "time": "Mon Apr 13 21:31:16 2009 -0700"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Tue Apr 14 11:31:50 2009 +0200"
      },
      "message": "rcu: Make hierarchical RCU less IPI-happy\n\nThis patch fixes a hierarchical-RCU performance bug located by Anton\nBlanchard.  The problem stems from a misguided attempt to provide a\nwork-around for jiffies-counter failure.  This work-around uses a per-CPU\nn_rcu_pending counter, which is incremented on each call to rcu_pending(),\nwhich in turn is called from each scheduling-clock interrupt.  Each CPU\nthen treats this counter as a surrogate for the jiffies counter, so\nthat if the jiffies counter fails to advance, the per-CPU n_rcu_pending\ncounter will cause RCU to invoke force_quiescent_state(), which in turn\nwill (among other things) send resched IPIs to CPUs that have thus far\nfailed to pass through an RCU quiescent state.\n\nUnfortunately, each CPU resets only its own counter after sending a\nbatch of IPIs.  This means that the other CPUs will also (needlessly)\nsend -another- round of IPIs, for a full N-squared set of IPIs in the\nworst case every three scheduler-clock ticks until the grace period\nfinally ends.  It is not reasonable for a given CPU to reset each and\nevery n_rcu_pending for all the other CPUs, so this patch instead simply\ndisables the jiffies-counter \"training wheels\", thus eliminating the\nexcessive IPIs.\n\nNote that the jiffies-counter IPIs do not have this problem due to\nthe fact that the jiffies counter is global, so that the CPU sending\nthe IPIs can easily reset things, thus preventing the other CPUs from\nsending redundant IPIs.\n\nNote also that the n_rcu_pending counter remains, as it will continue to\nbe used for tracing.  It may also see use to update the jiffies counter,\nshould an appropriate kick-the-jiffies-counter API appear.\n\nLocated-by: Anton Blanchard \u003canton@au1.ibm.com\u003e\nTested-by: Anton Blanchard \u003canton@au1.ibm.com\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nCc: anton@samba.org\nCc: akpm@linux-foundation.org\nCc: dipankar@in.ibm.com\nCc: manfred@colorfullife.com\nCc: cl@linux-foundation.org\nCc: josht@linux.vnet.ibm.com\nCc: schamp@sgi.com\nCc: niv@us.ibm.com\nCc: dvhltc@us.ibm.com\nCc: ego@in.ibm.com\nCc: laijs@cn.fujitsu.com\nCc: rostedt@goodmis.org\nCc: peterz@infradead.org\nCc: penberg@cs.helsinki.fi\nCc: andi@firstfloor.org\nCc: \"Paul E. McKenney\" \u003cpaulmck@linux.vnet.ibm.com\u003e\nLKML-Reference: \u003c12396834793575-git-send-email-\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "6258c4fb59e77d748f7efc2c137ad420372edd07",
      "tree": "c1e2ae0f027e81e55613b043ce44965858475d59",
      "parents": [
        "b1f77b0581b8fd837acb4a973f7d5496cae6efee"
      ],
      "author": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Wed Mar 25 16:42:24 2009 +0100"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Fri Apr 03 12:23:03 2009 +0200"
      },
      "message": "kmemtrace, rcu: fix rcu_tree_trace.c data structure dependencies\n\nImpact: cleanup\n\nWe want to remove rcutree internals from the public rcutree.h file for\nupcoming kmemtrace changes - but kernel/rcutree_trace.c depends on them.\n\nIntroduce kernel/rcutree.h for internal definitions. (Probably all\nthe other data types from include/linux/rcutree.h could be\nmoved here too - except rcu_data.)\n\nCc: Pekka Enberg \u003cpenberg@cs.helsinki.fi\u003e\nCc: Eduard - Gabriel Munteanu \u003ceduard.munteanu@linux360.ro\u003e\nCc: paulmck@linux.vnet.ibm.com\nLKML-Reference: \u003c1237898630.25315.83.camel@penberg-laptop\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "b1f77b0581b8fd837acb4a973f7d5496cae6efee",
      "tree": "4faa2e4285c31dd70d1d20b4172d1eed55ba7330",
      "parents": [
        "255d11bc910fd38153156a0c5ebb256657290882"
      ],
      "author": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Fri Mar 13 03:20:49 2009 +0100"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Fri Apr 03 12:23:02 2009 +0200"
      },
      "message": "kmemtrace, rcu: fix linux/rcutree.h and linux/rcuclassic.h dependencies\n\nImpact: build fix for all non-x86 architectures\n\nWe want to remove percpu.h from rcuclassic.h/rcutree.h (for upcoming\nkmemtrace changes) but that would break the DECLARE_PER_CPU based\ndeclarations in these files.\n\nMove the quiescent counter management functions to their respective\nRCU implementation .c files - they were slightly above the inlining\nlimit anyway.\n\nCc: Pekka Enberg \u003cpenberg@cs.helsinki.fi\u003e\nCc: Eduard - Gabriel Munteanu \u003ceduard.munteanu@linux360.ro\u003e\nCc: paulmck@linux.vnet.ibm.com\nLKML-Reference: \u003c1237898630.25315.83.camel@penberg-laptop\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "a682604838763981613e42015cd0e39f2989d6bb",
      "tree": "29eae425e484edc494807702696c240ce09ba3f5",
      "parents": [
        "694593e3374a67d95ece6a275a1f181644c2c4d8"
      ],
      "author": {
        "name": "Paul E. McKenney",
        "email": "paulmck@linux.vnet.ibm.com",
        "time": "Wed Feb 25 18:03:42 2009 -0800"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Thu Feb 26 04:08:14 2009 +0100"
      },
      "message": "rcu: Teach RCU that idle task is not quiscent state at boot\n\nThis patch fixes a bug located by Vegard Nossum with the aid of\nkmemcheck, updated based on review comments from Nick Piggin,\nIngo Molnar, and Andrew Morton.  And cleans up the variable-name\nand function-name language.  ;-)\n\nThe boot CPU runs in the context of its idle thread during boot-up.\nDuring this time, idle_cpu(0) will always return nonzero, which will\nfool Classic and Hierarchical RCU into deciding that a large chunk of\nthe boot-up sequence is a big long quiescent state.  This in turn causes\nRCU to prematurely end grace periods during this time.\n\nThis patch changes the rcutree.c and rcuclassic.c rcu_check_callbacks()\nfunction to ignore the idle task as a quiescent state until the\nsystem has started up the scheduler in rest_init(), introducing a\nnew non-API function rcu_idle_now_means_idle() to inform RCU of this\ntransition.  RCU maintains an internal rcu_idle_cpu_truthful variable\nto track this state, which is then used by rcu_check_callback() to\ndetermine if it should believe idle_cpu().\n\nBecause this patch has the effect of disallowing RCU grace periods\nduring long stretches of the boot-up sequence, this patch also introduces\nJosh Triplett\u0027s UP-only optimization that makes synchronize_rcu() be a\nno-op if num_online_cpus() returns 1.  This allows boot-time code that\ncalls synchronize_rcu() to proceed normally.  Note, however, that RCU\ncallbacks registered by call_rcu() will likely queue up until later in\nthe boot sequence.  Although rcuclassic and rcutree can also use this\nsame optimization after boot completes, rcupreempt must restrict its\nuse of this optimization to the portion of the boot sequence before the\nscheduler starts up, given that an rcupreempt RCU read-side critical\nsection may be preeempted.\n\nIn addition, this patch takes Nick Piggin\u0027s suggestion to make the\nsystem_state global variable be __read_mostly.\n\nChanges since v4:\n\no\tChanges the name of the introduced function and variable to\n\tbe less emotional.  ;-)\n\nChanges since v3:\n\no\tWARN_ON(nr_context_switches() \u003e 0) to verify that RCU\n\tswitches out of boot-time mode before the first context\n\tswitch, as suggested by Nick Piggin.\n\nChanges since v2:\n\no\tCreated rcu_blocking_is_gp() internal-to-RCU API that\n\tdetermines whether a call to synchronize_rcu() is itself\n\ta grace period.\n\no\tThe definition of rcu_blocking_is_gp() for rcuclassic and\n\trcutree checks to see if but a single CPU is online.\n\no\tThe definition of rcu_blocking_is_gp() for rcupreempt\n\tchecks to see both if but a single CPU is online and if\n\tthe system is still in early boot.\n\n\tThis allows rcupreempt to again work correctly if running\n\ton a single CPU after booting is complete.\n\no\tAdded check to rcupreempt\u0027s synchronize_sched() for there\n\tbeing but one online CPU.\n\nTested all three variants both SMP and !SMP, booted fine, passed a short\nrcutorture test on both x86 and Power.\n\nLocated-by: Vegard Nossum \u003cvegard.nossum@gmail.com\u003e\nTested-by: Vegard Nossum \u003cvegard.nossum@gmail.com\u003e\nTested-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "e4fa4c97016037620f9dc8bafe03e1086b665b4c",
      "tree": "130944c01e928d8a5e06aea635b222cb28515df8",
      "parents": [
        "a6525042bfdfcab128bd91fad264de10fd24a55e"
      ],
      "author": {
        "name": "Lai Jiangshan",
        "email": "laijs@cn.fujitsu.com",
        "time": "Wed Jan 14 14:58:15 2009 +0800"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Wed Jan 14 11:26:40 2009 +0100"
      },
      "message": "rcu: add __cpuinit to rcu_init_percpu_data()\n\nImpact: reduce memory footprint\n\nadd __cpuinit to rcu_init_percpu_data(), and this function\u0027s text\nwill be discarded after boot when !CONFIG_HOTPLUG_CPU.\n\nSigned-off-by: Lai Jiangshan \u003claijs@cn.fujitsu.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "90a4d2c0106bb690f0b6af3d506febc35c658aa7",
      "tree": "f62ee471a6d94fd94bfe97be339ab30ce7814e6f",
      "parents": [
        "c12172c0251761c54260376eb29a5f6547495580"
      ],
      "author": {
        "name": "Paul E. McKenney",
        "email": "paulmck@linux.vnet.ibm.com",
        "time": "Sun Jan 04 11:41:11 2009 -0800"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Mon Jan 05 10:12:33 2009 +0100"
      },
      "message": "rcu: make treercu safe for suspend and resume\n\nImpact: fix kernel warnings [and potential crash] during suspend+resume\n\nKudos to both Dhaval Giani and Jens Axboe for finding a bug in treercu\nthat causes warnings after suspend-resume cycles in Dhaval\u0027s case and\nduring stress tests in Jens\u0027s case.  It would also probably cause failures\nif heavily stressed.  The solution, ironically enough, is to revert to\nrcupreempt\u0027s code for initializing the dynticks state.  And the patch\neven results in smaller code -- so what was I thinking???\n\nThis is 2.6.29 material, given that people really do suspend and resume\nLinux these days.  ;-)\n\nReported-by: Dhaval Giani \u003cdhaval@linux.vnet.ibm.com\u003e\nReported-by: Jens Axboe \u003cjens.axboe@oracle.com\u003e\nTested-by: Dhaval Giani \u003cdhaval@linux.vnet.ibm.com\u003e\nTested-by: Jens Axboe \u003cjens.axboe@oracle.com\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "c12172c0251761c54260376eb29a5f6547495580",
      "tree": "b773010a88be3beeb4dfaf2658b76b40b448e98a",
      "parents": [
        "52942b6b16c6ebb25f4dd4df0208d840ba0cbc5c"
      ],
      "author": {
        "name": "Paul E. McKenney",
        "email": "paulmck@linux.vnet.ibm.com",
        "time": "Sun Jan 04 20:30:06 2009 -0800"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Mon Jan 05 10:10:28 2009 +0100"
      },
      "message": "rcu: fix rcutree grace-period-latency bug on small systems\n\nImpact: fix delays during bootup\n\nKudos to Andi Kleen for finding a grace-period-latency problem!  The\nproblem was that the special-case code for small machines never updated\nthe -\u003esignaled field to indicate that grace-period initialization had\ncompleted, which prevented force_quiescent_state() from ever expediting\ngrace periods.  This problem resulted in grace periods extending for more\nthan 20 seconds.  Not subtle.  I introduced this bug during my inspection\nprocess when I fixed a race between grace-period initialization and\nforce_quiescent_state() execution.\n\nThe following patch properly updates the -\u003esignaled field for the\n\"small\"-system case (no more than 32 CPUs for 32-bit kernels and no more\nthan 64 CPUs for 64-bit kernels).\n\nReported-by: Andi Kleen \u003candi@firstfloor.org\u003e\nTested-by: Andi Kleen \u003candi@firstfloor.org\u003e\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    },
    {
      "commit": "64db4cfff99c04cd5f550357edcc8780f96b54a2",
      "tree": "4856e788d21f0e31ed78a22b70b4521f7237705e",
      "parents": [
        "d110ec3a1e1f522e2e9dfceb9c36d6590c26d2d4"
      ],
      "author": {
        "name": "Paul E. McKenney",
        "email": "paulmck@linux.vnet.ibm.com",
        "time": "Thu Dec 18 21:55:32 2008 +0100"
      },
      "committer": {
        "name": "Ingo Molnar",
        "email": "mingo@elte.hu",
        "time": "Thu Dec 18 21:56:04 2008 +0100"
      },
      "message": "\"Tree RCU\": scalable classic RCU implementation\n\nThis patch fixes a long-standing performance bug in classic RCU that\nresults in massive internal-to-RCU lock contention on systems with\nmore than a few hundred CPUs.  Although this patch creates a separate\nflavor of RCU for ease of review and patch maintenance, it is intended\nto replace classic RCU.\n\nThis patch still handles stress better than does mainline, so I am still\ncalling it ready for inclusion.  This patch is against the -tip tree.\nNevertheless, experience on an actual 1000+ CPU machine would still be\nmost welcome.\n\nMost of the changes noted below were found while creating an rcutiny\n(which should permit ejecting the current rcuclassic) and while doing\ndetailed line-by-line documentation.\n\nUpdates from v9 (http://lkml.org/lkml/2008/12/2/334):\n\no\tFixes from remainder of line-by-line code walkthrough,\n\tincluding comment spelling, initialization, undesirable\n\tnarrowing due to type conversion, removing redundant memory\n\tbarriers, removing redundant local-variable initialization,\n\tand removing redundant local variables.\n\n\tI do not believe that any of these fixes address the CPU-hotplug\n\tissues that Andi Kleen was seeing, but please do give it a whirl\n\tin case the machine is smarter than I am.\n\n\tA writeup from the walkthrough may be found at the following\n\tURL, in case you are suffering from terminal insomnia or\n\tmasochism:\n\n\thttp://www.kernel.org/pub/linux/kernel/people/paulmck/tmp/rcutree-walkthrough.2008.12.16a.pdf\n\no\tMade rcutree tracing use seq_file, as suggested some time\n\tago by Lai Jiangshan.\n\no\tAdded a .csv variant of the rcudata debugfs trace file, to allow\n\tpeople having thousands of CPUs to drop the data into\n\ta spreadsheet.\tTested with oocalc and gnumeric.  Updated\n\tdocumentation to suit.\n\nUpdates from v8 (http://lkml.org/lkml/2008/11/15/139):\n\no\tFix a theoretical race between grace-period initialization and\n\tforce_quiescent_state() that could occur if more than three\n\tjiffies were required to carry out the grace-period\n\tinitialization.  Which it might, if you had enough CPUs.\n\no\tApply Ingo\u0027s printk-standardization patch.\n\no\tSubstitute local variables for repeated accesses to global\n\tvariables.\n\no\tFix comment misspellings and redundant (but harmless) increments\n\tof -\u003en_rcu_pending (this latter after having explicitly added it).\n\no\tApply checkpatch fixes.\n\nUpdates from v7 (http://lkml.org/lkml/2008/10/10/291):\n\no\tFixed a number of problems noted by Gautham Shenoy, including\n\tthe cpu-stall-detection bug that he was having difficulty\n\tconvincing me was real.  ;-)\n\no\tChanged cpu-stall detection to wait for ten seconds rather than\n\tthree in order to reduce false positive, as suggested by Ingo\n\tMolnar.\n\no\tProduced a design document (http://lwn.net/Articles/305782/).\n\tThe act of writing this document uncovered a number of both\n\ttheoretical and \"here and now\" bugs as noted below.\n\no\tFix dynticks_nesting accounting confusion, simplify WARN_ON()\n\tcondition, fix kerneldoc comments, and add memory barriers\n\tin dynticks interface functions.\n\no\tAdd more data to tracing.\n\no\tRemove unused \"rcu_barrier\" field from rcu_data structure.\n\no\tCount calls to rcu_pending() from scheduling-clock interrupt\n\tto use as a surrogate timebase should jiffies stop counting.\n\no\tFix a theoretical race between force_quiescent_state() and\n\tgrace-period initialization.  Yes, initialization does have to\n\tgo on for some jiffies for this race to occur, but given enough\n\tCPUs...\n\nUpdates from v6 (http://lkml.org/lkml/2008/9/23/448):\n\no\tFix a number of checkpatch.pl complaints.\n\no\tApply review comments from Ingo Molnar and Lai Jiangshan\n\ton the stall-detection code.\n\no\tFix several bugs in !CONFIG_SMP builds.\n\no\tFix a misspelled config-parameter name so that RCU now announces\n\tat boot time if stall detection is configured.\n\no\tRun tests on numerous combinations of configurations parameters,\n\twhich after the fixes above, now build and run correctly.\n\nUpdates from v5 (http://lkml.org/lkml/2008/9/15/92, bad subject line):\n\no\tFix a compiler error in the !CONFIG_FANOUT_EXACT case (blew a\n\tchangeset some time ago, and finally got around to retesting\n\tthis option).\n\no\tFix some tracing bugs in rcupreempt that caused incorrect\n\ttotals to be printed.\n\no\tI now test with a more brutal random-selection online/offline\n\tscript (attached).  Probably more brutal than it needs to be\n\ton the people reading it as well, but so it goes.\n\no\tA number of optimizations and usability improvements:\n\n\to\tMake rcu_pending() ignore the grace-period timeout when\n\t\tthere is no grace period in progress.\n\n\to\tMake force_quiescent_state() avoid going for a global\n\t\tlock in the case where there is no grace period in\n\t\tprogress.\n\n\to\tRearrange struct fields to improve struct layout.\n\n\to\tMake call_rcu() initiate a grace period if RCU was\n\t\tidle, rather than waiting for the next scheduling\n\t\tclock interrupt.\n\n\to\tInvoke rcu_irq_enter() and rcu_irq_exit() only when\n\t\tidle, as suggested by Andi Kleen.  I still don\u0027t\n\t\tcompletely trust this change, and might back it out.\n\n\to\tMake CONFIG_RCU_TRACE be the single config variable\n\t\tmanipulated for all forms of RCU, instead of the prior\n\t\tconfusion.\n\n\to\tDocument tracing files and formats for both rcupreempt\n\t\tand rcutree.\n\nUpdates from v4 for those missing v5 given its bad subject line:\n\no\tSeparated dynticks interface so that NMIs and irqs call separate\n\tfunctions, greatly simplifying it.  In particular, this code\n\tno longer requires a proof of correctness.  ;-)\n\no\tSeparated dynticks state out into its own per-CPU structure,\n\tavoiding the duplicated accounting.\n\no\tThe case where a dynticks-idle CPU runs an irq handler that\n\tinvokes call_rcu() is now correctly handled, forcing that CPU\n\tout of dynticks-idle mode.\n\no\tReview comments have been applied (thank you all!!!).\n\tFor but one example, fixed the dynticks-ordering issue that\n\tManfred pointed out, saving me much debugging.  ;-)\n\no\tAdjusted rcuclassic and rcupreempt to handle dynticks changes.\n\nAttached is an updated patch to Classic RCU that applies a hierarchy,\ngreatly reducing the contention on the top-level lock for large machines.\nThis passes 10-hour concurrent rcutorture and online-offline testing on\n128-CPU ppc64 without dynticks enabled, and exposes some timekeeping\nbugs in presence of dynticks (exciting working on a system where\n\"sleep 1\" hangs until interrupted...), which were fixed in the\n2.6.27 kernel.  It is getting more reliable than mainline by some\nmeasures, so the next version will be against -tip for inclusion.\nSee also Manfred Spraul\u0027s recent patches (or his earlier work from\n2004 at http://marc.info/?l\u003dlinux-kernel\u0026m\u003d108546384711797\u0026w\u003d2).\nWe will converge onto a common patch in the fullness of time, but are\ncurrently exploring different regions of the design space.  That said,\nI have already gratefully stolen quite a few of Manfred\u0027s ideas.\n\nThis patch provides CONFIG_RCU_FANOUT, which controls the bushiness\nof the RCU hierarchy.  Defaults to 32 on 32-bit machines and 64 on\n64-bit machines.  If CONFIG_NR_CPUS is less than CONFIG_RCU_FANOUT,\nthere is no hierarchy.  By default, the RCU initialization code will\nadjust CONFIG_RCU_FANOUT to balance the hierarchy, so strongly NUMA\narchitectures may choose to set CONFIG_RCU_FANOUT_EXACT to disable\nthis balancing, allowing the hierarchy to be exactly aligned to the\nunderlying hardware.  Up to two levels of hierarchy are permitted\n(in addition to the root node), allowing up to 16,384 CPUs on 32-bit\nsystems and up to 262,144 CPUs on 64-bit systems.  I just know that I\nam going to regret saying this, but this seems more than sufficient\nfor the foreseeable future.  (Some architectures might wish to set\nCONFIG_RCU_FANOUT\u003d4, which would limit such architectures to 64 CPUs.\nIf this becomes a real problem, additional levels can be added, but I\ndoubt that it will make a significant difference on real hardware.)\n\nIn the common case, a given CPU will manipulate its private rcu_data\nstructure and the rcu_node structure that it shares with its immediate\nneighbors.  This can reduce both lock and memory contention by multiple\norders of magnitude, which should eliminate the need for the strange\nmanipulations that are reported to be required when running Linux on\nvery large systems.\n\nSome shortcomings:\n\no\tMore bugs will probably surface as a result of an ongoing\n\tline-by-line code inspection.\n\n\tPatches will be provided as required.\n\no\tThere are probably hangs, rcutorture failures, \u0026c.  Seems\n\tquite stable on a 128-CPU machine, but that is kind of small\n\tcompared to 4096 CPUs.  However, seems to do better than\n\tmainline.\n\n\tPatches will be provided as required.\n\no\tThe memory footprint of this version is several KB larger\n\tthan rcuclassic.\n\n\tA separate UP-only rcutiny patch will be provided, which will\n\treduce the memory footprint significantly, even compared\n\tto the old rcuclassic.  One such patch passes light testing,\n\tand has a memory footprint smaller even than rcuclassic.\n\tInitial reaction from various embedded guys was \"it is not\n\tworth it\", so am putting it aside.\n\nCredits:\n\no\tManfred Spraul for ideas, review comments, and bugs spotted,\n\tas well as some good friendly competition.  ;-)\n\no\tJosh Triplett, Ingo Molnar, Peter Zijlstra, Mathieu Desnoyers,\n\tLai Jiangshan, Andi Kleen, Andy Whitcroft, and Andrew Morton\n\tfor reviews and comments.\n\no\tThomas Gleixner for much-needed help with some timer issues\n\t(see patches below).\n\no\tJon M. Tollefson, Tim Pepper, Andrew Theurer, Jose R. Santos,\n\tAndy Whitcroft, Darrick Wong, Nishanth Aravamudan, Anton\n\tBlanchard, Dave Kleikamp, and Nathan Lynch for keeping machines\n\talive despite my heavy abuse^Wtesting.\n\nSigned-off-by: Paul E. McKenney \u003cpaulmck@linux.vnet.ibm.com\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n"
    }
  ]
}