Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 3月, 2020 1 次提交
  3. 21 2月, 2020 4 次提交
  5. 20 2月, 2020 1 次提交
  7. 10 2月, 2020 1 次提交
  9. 05 2月, 2020 2 次提交
  11. 03 2月, 2020 3 次提交
    • R
      Documentation: admin-guide: PM: Update sleep states documentation · c21502ef
      由 Rafael J. Wysocki 提交于 
      There is some information in Documentation/power/interface.rst that
is still missing from Documentation/admin-guide/pm/sleep-states.rst
and really should be present in there, so update the latter by
adding that information to it and delete the former (as it becomes
redundant after that and it is somewhat outdated).

While at it, clean up some assorted pieces of sleep-states.rst a bit.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c21502ef
    • R
      intel_idle: Introduce 'states_off' module parameter · 4dcb78ee
      由 Rafael J. Wysocki 提交于 
      In certain system configurations it may not be desirable to use some
C-states assumed to be available by intel_idle and the driver needs
to be prevented from using them even before the cpuidle sysfs
interface becomes accessible to user space.  Currently, the only way
to achieve that is by setting the 'max_cstate' module parameter to a
value lower than the index of the shallowest of the C-states in
question, but that may be overly intrusive, because it effectively
makes all of the idle states deeper than the 'max_cstate' one go
away (and the C-state to avoid may be in the middle of the range
normally regarded as available).

To allow that limitation to be overcome, introduce a new module
parameter called 'states_off' to represent a list of idle states to
be disabled by default in the form of a bitmask and update the
documentation to cover it.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4dcb78ee
    • R
      intel_idle: Introduce 'use_acpi' module parameter · 3a5be9b8
      由 Rafael J. Wysocki 提交于 
      For diagnostics, it is generally useful to be able to make intel_idle
take the system's ACPI tables into consideration even if that is not
required for the processor model in there, so introduce a new module
parameter, 'use_acpi', to make that happen and update the documentation
to cover it.

While at it, fix the 'no_acpi' module parameter name in the
documentation.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3a5be9b8
  13. 01 2月, 2020 1 次提交
  15. 25 1月, 2020 4 次提交
  17. 22 1月, 2020 2 次提交
    • M
      genirq, sched/isolation: Isolate from handling managed interrupts · 11ea68f5
      由 Ming Lei 提交于 
      The affinity of managed interrupts is completely handled in the kernel and
cannot be changed via the /proc/irq/* interfaces from user space. As the
kernel tries to spread out interrupts evenly accross CPUs on x86 to prevent
vector exhaustion, it can happen that a managed interrupt whose affinity
mask contains both isolated and housekeeping CPUs is routed to an isolated
CPU. As a consequence IO submitted on a housekeeping CPU causes interrupts
on the isolated CPU.

Add a new sub-parameter 'managed_irq' for 'isolcpus' and the corresponding
logic in the interrupt affinity selection code.

The subparameter indicates to the interrupt affinity selection logic that
it should try to avoid the above scenario.

This isolation is best effort and only effective if the automatically
assigned interrupt mask of a device queue contains isolated and
housekeeping CPUs. If housekeeping CPUs are online then such interrupts are
directed to the housekeeping CPU so that IO submitted on the housekeeping
CPU cannot disturb the isolated CPU.

If a queue's affinity mask contains only isolated CPUs then this parameter
has no effect on the interrupt routing decision, though interrupts are only
happening when tasks running on those isolated CPUs submit IO. IO submitted
on housekeeping CPUs has no influence on those queues.

If the affinity mask contains both housekeeping and isolated CPUs, but none
of the contained housekeeping CPUs is online, then the interrupt is also
routed to an isolated CPU. Interrupts are only delivered when one of the
isolated CPUs in the affinity mask submits IO. If one of the contained
housekeeping CPUs comes online, the CPU hotplug logic migrates the
interrupt automatically back to the upcoming housekeeping CPU. Depending on
the type of interrupt controller, this can require that at least one
interrupt is delivered to the isolated CPU in order to complete the
migration.

[ tglx: Removed unused parameter, added and edited comments/documentation
  	and rephrased the changelog so it contains more details. ]
Signed-off-by: NMing Lei <ming.lei@redhat.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20200120091625.17912-1-ming.lei@redhat.com
      11ea68f5
    • M
      Documentation: bootconfig: Fix typos in bootconfig documentation · a4798eb4
      由 Masami Hiramatsu 提交于 
      Fix typos in bootconfig.rst according to Randy's suggestions.

Link: http://lkml.kernel.org/r/157949059219.25888.16939971423610233631.stgit@devnote2Suggested-by: NRandy Dunlap <rdunlap@infradead.org>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      a4798eb4
  19. 20 1月, 2020 1 次提交
    • A
      efi/x86: Limit EFI old memory map to SGI UV machines · 1f299fad
      由 Ard Biesheuvel 提交于 
      We carry a quirk in the x86 EFI code to switch back to an older
method of mapping the EFI runtime services memory regions, because
it was deemed risky at the time to implement a new method without
providing a fallback to the old method in case problems arose.

Such problems did arise, but they appear to be limited to SGI UV1
machines, and so these are the only ones for which the fallback gets
enabled automatically (via a DMI quirk). The fallback can be enabled
manually as well, by passing efi=old_map, but there is very little
evidence that suggests that this is something that is being relied
upon in the field.

Given that UV1 support is not enabled by default by the distros
(Ubuntu, Fedora), there is no point in carrying this fallback code
all the time if there are no other users. So let's move it into the
UV support code, and document that efi=old_map now requires this
support code to be enabled.

Note that efi=old_map has been used in the past on other SGI UV
machines to work around kernel regressions in production, so we
keep the option to enable it by hand, but only if the kernel was
built with UV support.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20200113172245.27925-8-ardb@kernel.org
      1f299fad
  21. 18 1月, 2020 1 次提交
  23. 17 1月, 2020 9 次提交
  25. 15 1月, 2020 1 次提交
  27. 14 1月, 2020 2 次提交
  29. 12 1月, 2020 1 次提交
  31. 11 1月, 2020 2 次提交
  33. 08 1月, 2020 2 次提交
  35. 27 12月, 2019 1 次提交
    • R
      cpuidle: Allow idle states to be disabled by default · 75a80267
      由 Rafael J. Wysocki 提交于 
      In certain situations it may be useful to prevent some idle states
from being used by default while allowing user space to enable them
later on.

For this purpose, introduce a new state flag, CPUIDLE_FLAG_OFF, to
mark idle states that should be disabled by default, make the core
set CPUIDLE_STATE_DISABLED_BY_USER for those states at the
initialization time and add a new state attribute in sysfs,
"default_status", to inform user space of the initial status of
the given idle state ("disabled" if CPUIDLE_FLAG_OFF is set for it,
"enabled" otherwise).
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      75a80267
  37. 22 12月, 2019 1 次提交