Currently io_ticks is approximated by adding one at each start and end of
requests if jiffies counter has changed. This works perfectly for requests
shorter than a jiffy or if one of requests starts/ends at each jiffy.

If disk executes just one request at a time and they are longer than two
jiffies then only first and last jiffies will be accounted.

Fix is simple: at the end of request add up into io_ticks jiffies passed
since last update rather than just one jiffy.

Example: common HDD executes random read 4k requests around 12ms.

fio --name=test --filename=/dev/sdb --rw=randread --direct=1 --runtime=30 &
iostat -x 10 sdb

Note changes of iostat's "%util" 8,43% -> 99,99% before/after patch:

Before:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0,00     0,00   82,60    0,00   330,40     0,00     8,00     0,96   12,09   12,09    0,00   1,02   8,43

After:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0,00     0,00   82,50    0,00   330,00     0,00     8,00     1,00   12,10   12,10    0,00  12,12  99,99

Now io_ticks does not loose time between start and end of requests, but
for queue-depth > 1 some I/O time between adjacent starts might be lost.

For load estimation "%util" is not as useful as average queue length,
but it clearly shows how often disk queue is completely empty.

Fixes: 5b18b5a7 ("block: delete part_round_stats and switch to less precise counting")
Signed-off-by: NKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>

Set paravirt_steal_rq_enabled if steal clock present.
paravirt_steal_rq_enabled is used in sched/core.c to adjust task
progress by offsetting stolen time. Use 'no-steal-acc' off switch (share
same name with KVM) to disable steal time accounting.
Signed-off-by: NAlexey Makhalov <amakhalov@vmware.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20200323195707.31242-5-amakhalov@vmware.com

URLs for presentation and Intel Software Developer’s Manual are updated
as they were using "http" which are gradually replaced by "https".
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

BGRT is for displaying seamless OEM logo from booting to login screen;
however, this mechanism does not always work well on all configurations
and the OEM logo can be displayed multiple times. This looks worse than
without BGRT enabled.

This patch adds a kernel parameter to disable BGRT in boot time. This is
easier than re-compiling a kernel with CONFIG_ACPI_BGRT disabled.
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 9c44bc03 ("softlockup: allow panic on lockup") added the
softlockup_panic sysctl, but didn't add information about it to the file
Documentation/admin-guide/sysctl/kernel.rst (which in that time certainly
wasn't rst and had other name!).

This patch just adds the respective documentation and references it from
the corresponding entry in Documentation/admin-guide/kernel-parameters.txt.

This patch was strongly based on Scott Wood's commit d22881dc
("Documentation: Better document the hardlockup_panic sysctl").
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGuilherme G. Piccoli <gpiccoli@canonical.com>
Link: https://lore.kernel.org/r/20200310183649.23163-1-gpiccoli@canonical.comSigned-off-by: NJonathan Corbet <corbet@lwn.net>

The virt_mechanism reference there points to a section
called elsewhere (Virtualization mitigation). Also, it is
not used anywere.

Besides that, it conflicts with a label with the same name
inside:

	Documentation/admin-guide/hw-vuln/mds.rst

Perhaps added due to some cut-and-paste?

Anyway, as this is not used, let's just get rid of it.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/681c8e2916bf4943ac2277f181668bfbc5fdbc01.1583250595.git.mchehab+huawei@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

    Documentation/admin-guide/perf/imx-ddr.rst:47: WARNING: Unexpected indentation.
Signed-off-by: NMauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/b27b54bd4f847032fd33313d6497ff320c0f3d78.1583250595.git.mchehab+huawei@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

Trim the title a bit, since it's relatively long. Add `binfmt_misc` to
make it easier to search for the feature by its common name.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20200308210935.7273-1-j.neuschaefer@gmx.netSigned-off-by: NJonathan Corbet <corbet@lwn.net>

Thermal pressure follows pelt signals which means the decay period for
thermal pressure is the default pelt decay period. Depending on SoC
characteristics and thermal activity, it might be beneficial to decay
thermal pressure slower, but still in-tune with the pelt signals.  One way
to achieve this is to provide a command line parameter to set a decay
shift parameter to an integer between 0 and 10.
Signed-off-by: NThara Gopinath <thara.gopinath@linaro.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lkml.kernel.org/r/20200222005213.3873-10-thara.gopinath@linaro.org

With the addition of fw_devlink kernel commandline option, of_devlink is
redundant and not useful anymore. So, delete it.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200222014038.180923-6-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

fwnode_operations.add_links allows creating device links from
information provided by firmware.

fwnode_operations.add_links is currently implemented only by
OF/devicetree code and a specific case of efi. However, there's nothing
preventing ACPI or other firmware types from implementing it.

The OF implementation is currently controlled by a kernel commandline
parameter called of_devlink.

Since this feature is generic isn't limited to OF, add a generic
fw_devlink kernel commandline parameter to control this feature across
firmware types.
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200222014038.180923-3-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When converting and moving nfsroot.txt to nfsroot.rst the references to
the old text file was not updated to match the change, fix this.

Fixes: f9a93498 ("Documentation: nfsroot.txt: convert to ReST")
Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200212181332.520545-1-niklas.soderlund+renesas@ragnatech.seSigned-off-by: NJonathan Corbet <corbet@lwn.net>

The set of WQ_SYSFS workqueues should be displayed using
"ls /sys/devices/virtual/workqueue", add the missing '/'.
Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
Link: https://lore.kernel.org/r/20200225124052.1506-1-yuzenghui@huawei.comSigned-off-by: NJonathan Corbet <corbet@lwn.net>

Annotate references to other documents to make them clickable.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/r/20200228000653.1572553-6-kuba@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

We need literal sections otherwise the entire example is rendered
as a single line.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/r/20200228000653.1572553-5-kuba@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

We need a literal section, like few paragraphs below.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/r/20200228000653.1572553-4-kuba@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

If there is an empty line between item and description
Sphinx does not emphasize the item. First half of the
list does not have the empty line and is emphasized
correctly.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/r/20200228000653.1572553-3-kuba@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

Fix tabs vs spaces issue which cases the line to be considered
a new list entry.
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Acked-by: NJohannes Weiner <hannes@cmpxchg.org>
Link: https://lore.kernel.org/r/20200228000653.1572553-2-kuba@kernel.orgSigned-off-by: NJonathan Corbet <corbet@lwn.net>

drivers/tty/serial/imx.c implements these earlycon options.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20200229132750.2783-1-j.neuschaefer@gmx.netSigned-off-by: NJonathan Corbet <corbet@lwn.net>

There are three legacy driver documents in Documentation/cpu-freq/
that were added years ago and converting them each to the .rst
format is rather pointless, even though there is some value in
preserving them.  However, if they are preserved, they need to go
into the admin-guide part of cpufreq documentation where they belong
(at least to a certain extent).

To preserve them with minimum amount of changes and put them into the
right place, and make it possible to process them into HTML (and other
formats) along with the rest of the documentation, move them each
as a "literal text" block into a separate section of a single .rst
"wrapper" file under Documentation/admin-guide/pm/.

While at it, repair the PCC specification URL in one of them.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This script allows sysctl documentation to be checked against the
kernel source code, to identify missing or obsolete entries. Running
it against 5.5 shows for example that sysctl/kernel.rst has two
obsolete entries and is missing 52 entries.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

"untrusted" was mis-spelled as "unstrusted"
Signed-off-by: NAlex Hung <alex.hung@canonical.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Based on the implementation in arch/x86/kernel/acpi/sleep.c, in
particular the acpi_sleep_setup() function.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Add append value operator "+=" support to bootconfig syntax.
With this operator, user can add new value to the key as
an entry of array instead of overwriting.
For example,

  foo = bar
  ...
  foo += baz

Then the key "foo" has "bar" and "baz" values as an array.

Link: http://lkml.kernel.org/r/158227283195.12842.8310503105963275584.stgit@devnote2Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>

Currently, bootconfig adds a new value on the existing key to the tail of an
array. But this looks a bit confusing because an admin can easily rewrite
the original value in the same config file.

This rejects the following value re-definition.

  key = value1
  ...
  key = value2

You should rewrite value1 to value2 in this case.

Link: http://lkml.kernel.org/r/158227282199.12842.10110929876059658601.stgit@devnote2Suggested-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
[ Fixed spelling of arraies to arrays ]
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>

In theory, RCU-hotplug operations are supposed to work as soon as there
is more than one CPU online.  However, in practice, in normal production
there is no way to make them happen until userspace is up and running.
Besides which, on smaller systems, rcutorture doesn't start doing hotplug
operations until 30 seconds after the start of boot, which on most
systems also means the better part of 30 seconds after the end of boot.
This commit therefore provides a new torture.disable_onoff_at_boot kernel
boot parameter that suppresses CPU-hotplug torture operations until
about the time that init is spawned.

Of course, if you know of a need for boottime CPU-hotplug operations,
then you should avoid passing this argument to any of the torture tests.
You might also want to look at the splats linked to below.

Link: https://lore.kernel.org/lkml/20191206185208.GA25636@paulmck-ThinkPad-P72/Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>

In normal production, an RCU CPU stall warning at boottime is often
just as bad as at any other time.  In fact, given the desire for fast
boot, any sort of long-term stall at boot is a bad idea.  However,
heavy rcutorture testing on large hyperthreaded systems can generate
boottime RCU CPU stalls as a matter of course.  This commit therefore
provides a kernel boot parameter that suppresses reporting of boottime
RCU CPU stall warnings and similarly of rcutorture writer stalls.
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>

In default configutions, RCU currently waits at least 100 milliseconds
before asking cond_resched() and/or resched_rcu() for help seeking
quiescent states to end a grace period.  But 100 milliseconds can be
one good long time during an RCU callback flood, for example, as can
happen when user processes repeatedly open and close files in a tight
loop.  These 100-millisecond gaps in successive grace periods during a
callback flood can result in excessive numbers of callbacks piling up,
unnecessarily increasing memory footprint.

This commit therefore asks cond_resched() and/or resched_rcu() for help
as early as the first FQS scan when at least one of the CPUs has more
than 20,000 callbacks queued, a number that can be changed using the new
rcutree.qovld kernel boot parameter.  An auxiliary qovld_calc variable
is used to avoid acquisition of locks that have not yet been initialized.
Early tests indicate that this reduces the RCU-callback memory footprint
during rcutorture floods by from 50% to 4x, depending on configuration.
Reported-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
Reported-by: NTejun Heo <tj@kernel.org>
[ paulmck: Fix bug located by Qian Cai. ]
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
Tested-by: NDexuan Cui <decui@microsoft.com>
Tested-by: NQian Cai <cai@lca.pw>

Reject if a value node is mixed with subkey node on same
parent key node.

A value node can not co-exist with subkey node under some key
node, e.g.

key = value
key.subkey = another-value

This is not be allowed because bootconfig API is not designed
to handle such case.

Link: http://lkml.kernel.org/r/158220115232.26565.7792340045009731803.stgit@devnote2Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>

Add bootconfig magic word to the end of bootconfig on initrd
image for indicating explicitly the bootconfig is there.
Also tools/bootconfig treats wrong size or wrong checksum or
parse error as an error, because if there is a bootconfig magic
word, there must be a bootconfig.

The bootconfig magic word is "#BOOTCONFIG\n", 12 bytes word.
Thus the block image of the initrd file with bootconfig is
as follows.

[Initrd][bootconfig][size][csum][#BOOTCONFIG\n]

Link: http://lkml.kernel.org/r/158220112263.26565.3944814205960612841.stgit@devnote2Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>

A split-lock occurs when an atomic instruction operates on data that spans
two cache lines. In order to maintain atomicity the core takes a global bus
lock.

This is typically >1000 cycles slower than an atomic operation within a
cache line. It also disrupts performance on other cores (which must wait
for the bus lock to be released before their memory operations can
complete). For real-time systems this may mean missing deadlines. For other
systems it may just be very annoying.

Some CPUs have the capability to raise an #AC trap when a split lock is
attempted.

Provide a command line option to give the user choices on how to handle
this:

split_lock_detect=
	off	- not enabled (no traps for split locks)
	warn	- warn once when an application does a
		  split lock, but allow it to continue
		  running.
	fatal	- Send SIGBUS to applications that cause split lock

On systems that support split lock detection the default is "warn". Note
that if the kernel hits a split lock in any mode other than "off" it will
OOPs.

One implementation wrinkle is that the MSR to control the split lock
detection is per-core, not per thread. This might result in some short
lived races on HT systems in "warn" mode if Linux tries to enable on one
thread while disabling on the other. Race analysis by Sean Christopherson:

  - Toggling of split-lock is only done in "warn" mode.  Worst case
    scenario of a race is that a misbehaving task will generate multiple
    #AC exceptions on the same instruction.  And this race will only occur
    if both siblings are running tasks that generate split-lock #ACs, e.g.
    a race where sibling threads are writing different values will only
    occur if CPUx is disabling split-lock after an #AC and CPUy is
    re-enabling split-lock after *its* previous task generated an #AC.
  - Transitioning between off/warn/fatal modes at runtime isn't supported
    and disabling is tracked per task, so hardware will always reach a steady
    state that matches the configured mode.  I.e. split-lock is guaranteed to
    be enabled in hardware once all _TIF_SLD threads have been scheduled out.
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Co-developed-by: NFenghua Yu <fenghua.yu@intel.com>
Signed-off-by: NFenghua Yu <fenghua.yu@intel.com>
Co-developed-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20200126200535.GB30377@agluck-desk2.amr.corp.intel.com

Fix Sphinx format warnings in fan_performace_states.rst
by adding indentation.

Documentation/admin-guide/acpi/fan_performance_states.rst:21: WARNING: Literal block ends without a blank line; unexpected unindent.
Documentation/admin-guide/acpi/fan_performance_states.rst:41: WARNING: Literal block expected; none found.
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

When both the documentation and the data files lived in
Documentation/EDID, this wasn't necessary, but both have
been moved to other directories in the meantime.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This document describes actions that an admin can do, rather than
interfaces available to driver developers, so admin-guide seems to
be a more appropriate place for it.
Signed-off-by: NJonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

These have no corresponding code in the kernel.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The description of panic doesn’t cover all the supported scenarios;
this patch fixes that, describing the three possibilities (no reboot,
immediate reboot, reboot after a delay).

Based on the implementation in kernel/panic.c.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This describes the SPARC-specific stop-a sysctl entry, which was
previously listed in kernel.rst but not documented.

Base on the implementation in arch/sparc/kernel/setup_{32,64}.c and
kernel/panic.c.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This adds short descriptions of msgmax, msgmnb, msgmni, and shmmni,
which were previously listed in kernel.rst but not described.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The l2cr sysctl entry was removed in commit c2f3dabe ("sysctl:
kill binary sysctl KERN_PPC_L2CR"), this removes the corresponding
documentation.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This fits nicely in sysctl/kernel.rst, merge it (and rephrase it)
instead of linking to it.
Signed-off-by: NStephen Kitt <steve@sk2.org>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>