Merge branch 'icc-sdx55' into icc-next

the bottom of the diagram above).

Plumbing this into the full grace-period execution is described

`below <#Forcing%20Quiescent%20States>`__.

`below <Forcing Quiescent States_>`__.

CPU-Hotplug Interface

^^^^^^^^^^^^^^^^^^^^^

grace period.

Plumbing this into the full grace-period execution is described

`below <#Forcing%20Quiescent%20States>`__.

`below <Forcing Quiescent States_>`__.

Forcing Quiescent States

^^^^^^^^^^^^^^^^^^^^^^^^

| RCU. But this diagram is complex enough as it is, so simplicity       |

| overrode accuracy. You can think of it as poetic license, or you can  |

| think of it as misdirection that is resolved in the                   |

| `stitched-together diagram <#Putting%20It%20All%20Together>`__.       |

| `stitched-together diagram <Putting It All Together_>`__.             |

+-----------------------------------------------------------------------+

Grace-Period Cleanup

that runs on some other CPU, proper ordering must in place in both the

callback function and the task being awakened. To see why this is

important, consider the top half of the `grace-period

cleanup <#Grace-Period%20Cleanup>`__ diagram. The callback might be

cleanup`_ diagram. The callback might be

running on a CPU corresponding to the leftmost leaf ``rcu_node``

structure, and awaken a task that is to run on a CPU corresponding to

the rightmost leaf ``rcu_node`` structure, and the grace-period kernel

#. `Other RCU Flavors`_

#. `Possible Future Changes`_

This is followed by a `summary <#Summary>`__, however, the answers to

This is followed by a summary_, however, the answers to

each quick quiz immediately follows the quiz. Select the big white space

with your mouse to see the answer.

| case, voluntary context switch) within an RCU read-side critical      |

| section. However, sleeping locks may be used within userspace RCU     |

| read-side critical sections, and also within Linux-kernel sleepable   |

| RCU `(SRCU) <#Sleepable%20RCU>`__ read-side critical sections. In     |

| RCU `(SRCU) <Sleepable RCU_>`__ read-side critical sections. In       |

| addition, the -rt patchset turns spinlocks into a sleeping locks so   |

| that the corresponding critical sections can be preempted, which also |

| means that these sleeplockified spinlocks (but not other sleeping     |

RCU <https://lkml.kernel.org/g/20090113221724.GA15307@linux.vnet.ibm.com>`__

was born. Josh Triplett has since taken over the small-memory banner

with his `Linux kernel tinification <https://tiny.wiki.kernel.org/>`__

project, which resulted in `SRCU <#Sleepable%20RCU>`__ becoming optional

project, which resulted in `SRCU <Sleepable RCU_>`__ becoming optional

for those kernels not needing it.

The remaining performance requirements are, for the most part,

the relevant Kconfig options and kernel boot parameters. RCU currently

does not do much sanity checking of these parameters, so please use

caution when changing them. Note that these forward-progress measures

are provided only for RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks

RCU <#Tasks%20RCU>`__.

are provided only for RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks

RCU`_.

RCU takes the following steps in ``call_rcu()`` to encourage timely

invocation of callbacks when any given non-\ ``rcu_nocbs`` CPU has

Again, these are default values when running at ``HZ=1000``, and can be

overridden. Again, these forward-progress measures are provided only for

RCU, not for `SRCU <#Sleepable%20RCU>`__ or `Tasks

RCU <#Tasks%20RCU>`__. Even for RCU, callback-invocation forward

RCU, not for `SRCU <Sleepable RCU_>`__ or `Tasks

RCU`_. Even for RCU, callback-invocation forward

progress for ``rcu_nocbs`` CPUs is much less well-developed, in part

because workloads benefiting from ``rcu_nocbs`` CPUs tend to invoke

``call_rcu()`` relatively infrequently. If workloads emerge that need

The Linux kernel supports CPU hotplug, which means that CPUs can come

and go. It is of course illegal to use any RCU API member from an

offline CPU, with the exception of `SRCU <#Sleepable%20RCU>`__ read-side

offline CPU, with the exception of `SRCU <Sleepable RCU_>`__ read-side

critical sections. This requirement was present from day one in

DYNIX/ptx, but on the other hand, the Linux kernel's CPU-hotplug

implementation is “interesting.”

However, RCU must be reliably informed as to whether any given CPU is

currently in the idle loop, and, for ``NO_HZ_FULL``, also whether that

CPU is executing in usermode, as discussed

`earlier <#Energy%20Efficiency>`__. It also requires that the

`earlier <Energy Efficiency_>`__. It also requires that the

scheduling-clock interrupt be enabled when RCU needs it to be:

#. If a CPU is either idle or executing in usermode, and RCU believes it

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Expanding on the `earlier

discussion <#Performance%20and%20Scalability>`__, RCU is used heavily by

discussion <Performance and Scalability_>`__, RCU is used heavily by

hot code paths in performance-critical portions of the Linux kernel's

networking, security, virtualization, and scheduling code paths. RCU

must therefore use efficient implementations, especially in its

- ``name``

   is an identifier string. A new /proc file will be created with this

   ``name below /proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for

   name below ``/proc/sys/fs/binfmt_misc``; cannot contain slashes ``/`` for

   obvious reasons.

- ``type``

   is the type of recognition. Give ``M`` for magic and ``E`` for extension.

      ``F`` - fix binary

            The usual behaviour of binfmt_misc is to spawn the

	    binary lazily when the misc format file is invoked.  However,

	    this doesn``t work very well in the face of mount namespaces and

	    this doesn't work very well in the face of mount namespaces and

	    changeroots, so the ``F`` mode opens the binary as soon as the

	    emulation is installed and uses the opened image to spawn the

	    emulator, meaning it is always available once installed,

Because of this "piggyback" method, there is no need to change or

update the boot loader and the kernel image itself as long as the boot

loader passes the correct initrd file size. If by any chance, the boot

loader passes a longer size, the kernel feils to find the bootconfig data.

loader passes a longer size, the kernel fails to find the bootconfig data.

To do this operation, Linux kernel provides "bootconfig" command under

tools/bootconfig, which allows admin to apply or delete the config file

The kernel's command-line parameters

====================================

The following is a consolidated list of the kernel parameters as

implemented by the __setup(), core_param() and module_param() macros

The following is a consolidated list of the kernel parameters as implemented

by the __setup(), early_param(), core_param() and module_param() macros

and sorted into English Dictionary order (defined as ignoring all

punctuation and sorting digits before letters in a case insensitive

manner), and with descriptions where known.