From: Andrew Jones
commit 75df529bec9110dad43ab30e2d9490242529e8b8 upstream.
Steal time initialization requires mapping a memory region which
invokes a memory allocation. Doing this at CPU starting time results
in the following trace when CONFIG_DEBUG_ATOMIC_SLEEP is enabled:
BUG: sleeping
Add the enable time for LDOs.
This patch is preparing for adding mt6359p regulator support.
Signed-off-by: Hsin-Hsiung Wang
Acked-by: Mark Brown
---
drivers/regulator/mt6359-regulator.c | 65 +++-
1 file changed, 42 insertions(+), 23 deletions(-)
diff --git
Hi Steve,
Can you also merge this series to tracing tree?
Thank you,
On Sat, 15 Aug 2020 23:01:00 +0900
Masami Hiramatsu wrote:
> Hi,
>
> This is the 2nd version of the series to introduce scripts for the
> boot-time tracing. In this version, I just updated 4/6 according to
>
We only update the tg->last_finish_time when the low limitaion is
enabled, so we can move the tg->last_finish_time validation a little
forward to avoid getting the unnecessary current time stamp if the
the low limitation is not enabled.
Signed-off-by: Baolin Wang
---
block/blk-throttle
On 09/18/20 at 05:47pm, Andrew Morton wrote:
> On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
>
> > crash_kexec_post_notifiers enables running various panic notifier
> > before kdump kernel booting. This increases risks of kdump failure.
> > It is well documented in kernel-parameters.txt.
On Fri, 18 Sep 2020 11:25:46 +0800 Dave Young wrote:
> crash_kexec_post_notifiers enables running various panic notifier
> before kdump kernel booting. This increases risks of kdump failure.
> It is well documented in kernel-parameters.txt. We do not suggest
> people to enable it together with
The Real-Time Mini-Summit is organized by the Linux Foundation Real-Time Linux
(RTL) collaborative project. The event is intended to gather developers and
users of Linux as a Real-Time Operating System. The main intent is to provide
room for discussion between developers, tooling experts
Hi, Marc,
I measured the time from vcpu_load() (include it) to __guest_enter() on Kunpeng
920. On average, It takes 2.55 microseconds (not first run && the VPT is
empty). So waiting for 10 microseconds in
vcpu scheduling really hurts performance.
And I agree that delaying the e
crash_kexec_post_notifiers enables running various panic notifier
before kdump kernel booting. This increases risks of kdump failure.
It is well documented in kernel-parameters.txt. We do not suggest
people to enable it together with kdump unless he/she is really sure.
This is also not suggested
From: Arnd Bergmann
[ Upstream commit d68f4e43a46ff1f772ff73085f96d44eb4163e9d ]
The mt76_led_cleanup() function is called unconditionally, which
leads to a link error when CONFIG_LEDS is a loadable module or
disabled but mt76 is built-in:
drivers/net/wireless/mediatek/mt76/mac80211.o: In
system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked fo
system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked fo
system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked fo
system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked fo
system that can be used for buffering. To write 4
GB of buffer to disk thus takes ~4000 MB / ~15 MB/s = ~267 seconds.
The 267 second number is a problem because in __blkdev_put() we call
sync_blockdev() while holding the bd_mutex. Any other callers who
want the bd_mutex will be blocked fo
On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> From: Jiang Biao
>
> pci_read_config() could block several ms in kernel space, mainly
> caused by the while loop to call pci_user_read_config_dword().
> Singel pci_user_read_config_dword() loop could consume 130us+,
> |
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, September 15, 2020 8:45 PM
> To: Zengtao (B)
> Cc: Thomas Gleixner; Vincenzo Frascino; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] time: Avoid undefined behaviour in
> timespe
Hi,
On Thu, 17 Sep 2020 at 00:56, Bjorn Helgaas wrote:
>
> On Sun, Sep 13, 2020 at 12:27:09PM +0800, Jiang Biao wrote:
> > On Thu, 10 Sep 2020 at 09:59, Bjorn Helgaas wrote:
> > > On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> > > > On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas
v2: Add more description text in the new Kconfig settings (Bjorn).
v1: Original
Jim Quinlan (1):
PCI: pcie_bus_config can be set at build time
drivers/pci/Kconfig | 56 +
drivers/pci/pci.c | 12 ++
2 files changed, 68 insertions
The Kconfig is modified so that the pcie_bus_config setting can be done at
build time in the same manner as the CONFIG_PCIEASPM_ choice. The
pci_bus_config setting may still be overridden by the bootline param.
Signed-off-by: Jim Quinlan
---
drivers/pci/Kconfig | 56
In vidtv_mux_check_mux_rate(), the function jiffies_to_usecs() is called
but its output is treated as if it were a value in milliseconds (indeed,
it is assigned to a variable called elapsed_time_msecs). Accordingly,
the calculation will be off by a factor of 1000. Fix this.
Addresses-Coverity:
Committer: Thomas Gleixner
CommitterDate: Wed, 16 Sep 2020 16:52:35 +02:00
x86/irq: Initialize PCI/MSI domain at PCI init time
No point in initializing the default PCI/MSI interrupt domain early and no
point to create it when XEN PV/HVM/DOM0 are active.
Move the initialization to pci_arch_init
On Sun, Sep 13, 2020 at 12:27:09PM +0800, Jiang Biao wrote:
> On Thu, 10 Sep 2020 at 09:59, Bjorn Helgaas wrote:
> > On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> > > On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> > > > On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao
ng
latency of a vcpu you said, which includes many events. Is the parse
time of
the VPT not clear enough?
Measure the time it takes from kvm_vcpu_load() to the point where the
vcpu
enters the guest. How much, in proportion, do these 1/2/10ms represent?
Also, a better(?) course of action w
of the total scheduling
latency of a vcpu you said, which includes many events. Is the parse time of
the VPT not clear enough?
-Original Message-
From: Marc Zyngier [mailto:m...@kernel.org]
Sent: 2020-09-15 22:48
To: lushenming
Cc: Thomas Gleixner ; Jason Cooper ;
linux-kernel
Thanks for your quick response.
Okay, I agree that busy-waiting may add more overhead at the RD level. But I
think that the delay time can be adjusted. In our latest hardware
implementation, we optimize the search of the VPT, now even the VPT full of
interrupts (56k) can be parsed within 2
On 2020-09-15 15:04, lushenming wrote:
Thanks for your quick response.
Okay, I agree that busy-waiting may add more overhead at the RD level.
But I think that the delay time can be adjusted. In our latest
hardware implementation, we optimize the search of the VPT, now even
the VPT full
t; only if "next_prio" is less than
100 (note lower inside the kernel means higher priority, so these are only
real time tasks).
# echo 1 > events/synthetic/latency/enable
# cat trace
sshd-1049 [000] d...411 3739.316424: latency: lat=3 pid=277
prio=49
On Tue, Sep 15, 2020 at 2:20 PM Zengtao (B) wrote:
> > > Fixes: bd40a175769d ("y2038: itimer: change implementation to
> > timespec64")
> >
> > This one caused the regression, but if we add the check here, it
> > may be best to also add it in prior kernels that may have the same
> > bug in other
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, September 01, 2020 8:47 PM
> To: Zengtao (B)
> Cc: Thomas Gleixner; Vincenzo Frascino; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] time: Avoid undefined behaviour in
> timespe
On 2020-09-15 08:22, Shenming Lu wrote:
Every time the vPE is scheduled, the code starts polling the
GICR_VPENDBASER.Dirty bit until it becomes 0. It's OK. But
the delay_us of the poll function is directly set to 10, which
is a long time for most interrupts. In our measurement, it takes
only 1~2
Every time the vPE is scheduled, the code starts polling the
GICR_VPENDBASER.Dirty bit until it becomes 0. It's OK. But
the delay_us of the poll function is directly set to 10, which
is a long time for most interrupts. In our measurement, it takes
only 1~2 microseconds, or even hundreds
ide ndis driver needs quite
> more time to be loaded and configured, so that the linux rndis host queries
> to them fail to be responded correctly on time.
>
> More specifically, when INIT is called on the WinCE side - no other
> requests can be served by the Client and this results
From: Bartosz Golaszewski
The time buffer len is used directly in this driver. For readability
it's better to define it as the difference between the date register
offsets and use sizeof() whenever referencing it.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 11
Hi, Bjorn
On Thu, 10 Sep 2020 at 09:59, Bjorn Helgaas wrote:
>
> On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> > Hi,
> >
> > On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> > >
> > > On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> > > > From: Jiang Biao
> > >
Some WinCE devices face connectivity issues via the NDIS interface. They
fail to register, resulting in -110 timeout errors and failures during the
probe procedure.
In this kind of WinCE devices, the Windows-side ndis driver needs quite
more time to be loaded and configured, so that the linux
Matthias, gentle ping on the patch below >>>
Thanks!
On Thu, Jul 30, 2020 at 12:01 PM Nicolas Boichat wrote:
>
> In the error case, where a power domain cannot be powered on
> successfully at boot time (in mtk_register_power_domains),
> pm_genpd_init would still be cal
Add tracing_on option description to the boot-time tracer.
Signed-off-by: Masami Hiramatsu
---
Changes in v3.1:
- Fix "on boot" to "on starting boot-time tracing".
---
Documentation/trace/boottime-trace.rst |4
1 file changed, 4 insertions(+)
diff --git a
Hi Tim,
On Thu, 10 Sep 2020 13:26:05 +
"Bird, Tim" wrote:
>
>
> > -Original Message-
> > From: Masami Hiramatsu
> >
> > Add tracing_on option description to the boot-time tracer.
> >
> > Signed-off-by: Masami Hiramatsu
> &
Hi,
Here is a series of patches which starts the boot-time tracing earlier,
core_initcall_sync, so that we can start tracing from postcore_initcall
instead of device_initcall.
The boot-time tracing is useful for debugging kernel drivers which are
embedded in the kernel. Since most of the drivers
Hi Bjorn,
On Wed, Sep 9, 2020 at 10:25 PM Bjorn Helgaas wrote:
>
> On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote:
> > The Kconfig is modified so that the pcie_bus_config setting can be done at
> > build time in the same manner as the CONFIG_PC
From: Bartosz Golaszewski
The time buffer len is used directly in this driver. For readability
it's better to define it as the difference between the date register
offsets and use sizeof() whenever referencing it.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 11
On Thu, Sep 10, 2020 at 08:57:10AM -0400, Jim Quinlan wrote:
> Hi Bjorn,
>
> On Wed, Sep 9, 2020 at 10:25 PM Bjorn Helgaas wrote:
> >
> > On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote:
> > > The Kconfig is modified so that the pcie_bus_config setting c
(-)
diff --git a/Makefile b/Makefile
index 5102c89d3167..1d7c58684fda 100644
--- a/Makefile
+++ b/Makefile
@@ -940,7 +940,7 @@ KBUILD_CFLAGS += -fno-stack-check
KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
# Prohibit date/time macros, which would make the build non-deterministic
w.
>
> Call netvsc_vf_changed() in the NETDEV_CHANGE event handler: at that time
> the mlx5 VF NIC has been resumed.
>
> Fixes: 19162fd4063a ("hv_netvsc: Fix hibernation for mlx5 VF driver")
> Signed-off-by: Dexuan Cui
Applied.
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:28 +02:00
time/sched_clock: Use raw_read_seqcount_latch() during suspend
sched_clock uses seqcount_t latching to switch between two storage
places protected by the sequence counter. This allows it to have
interruptible, NMI-safe
Committer: Peter Zijlstra
CommitterDate: Thu, 10 Sep 2020 11:19:29 +02:00
time/sched_clock: Use seqcount_latch_t
Latch sequence counters have unique read and write APIs, and thus
seqcount_latch_t was recently introduced at seqlock.h.
Use that new data type instead of plain seqcount_t
t; index 5102c89d3167..1d7c58684fda 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -940,7 +940,7 @@ KBUILD_CFLAGS += -fno-stack-check
> KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
>
> # Prohibit date/time macros, which would make the build non-deterministic
> -KBUILD_C
> -Original Message-
> From: Masami Hiramatsu
>
> Add tracing_on option description to the boot-time tracer.
>
> Signed-off-by: Masami Hiramatsu
> ---
> Documentation/trace/boottime-trace.rst |4
> 1 file changed, 4 insertions(+)
>
>
Initialize boot-time tracing in core_initcall_sync instead of
fs_initcall, and initialize required tracers (kprobes and synth)
in core_initcall. This will allow the boot-time tracing to trace
__init code from the beginning of postcore_initcall stage.
Signed-off-by: Masami Hiramatsu
---
kernel
Add the note about when to start the boot-time tracing.
This will be needed for the people who wants to trace
earlier boot sequence.
Signed-off-by: Masami Hiramatsu
---
Documentation/trace/boottime-trace.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation
Add tracing_on option description to the boot-time tracer.
Signed-off-by: Masami Hiramatsu
---
Documentation/trace/boottime-trace.rst |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/trace/boottime-trace.rst
b/Documentation/trace/boottime-trace.rst
index dcb390075ca1
On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> Hi,
>
> On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> >
> > On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> > > From: Jiang Biao
> > >
> > > pci_read_config() could block several ms in kernel space, mainly
> > >
On Tue, Sep 08, 2020 at 12:32:48PM -0400, Jim Quinlan wrote:
> The Kconfig is modified so that the pcie_bus_config setting can be done at
> build time in the same manner as the CONFIG_PCIEASPM_ choice. The
> pci_bus_config setting may still be overridden by the bootline param.
I gu
Hi,
On Thu, 10 Sep 2020 at 09:59, Bjorn Helgaas wrote:
>
> On Thu, Sep 10, 2020 at 09:54:02AM +0800, Jiang Biao wrote:
> > Hi,
> >
> > On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
> > >
> > > On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> > > > From: Jiang Biao
> > > >
> >
Hi,
On Thu, 10 Sep 2020 at 09:25, Bjorn Helgaas wrote:
>
> On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> > From: Jiang Biao
> >
> > pci_read_config() could block several ms in kernel space, mainly
> > caused by the while loop to call pci_user_read_config_dword().
> > Singel
On Mon, Aug 24, 2020 at 01:20:25PM +0800, Jiang Biao wrote:
> From: Jiang Biao
>
> pci_read_config() could block several ms in kernel space, mainly
> caused by the while loop to call pci_user_read_config_dword().
> Singel pci_user_read_config_dword() loop could consume 130us+,
> |
When netvsc_resume() is called, the mlx5 VF NIC has not been resumed yet,
so in the future the host might sliently fail the call netvsc_vf_changed()
-> netvsc_switch_datapath() there, even if the call works now.
Call netvsc_vf_changed() in the NETDEV_CHANGE event handler: at that time
the mlx5
On Tue, 2020-09-08 at 17:06 +0200, Sebastian Andrzej Siewior wrote:
>
> This should cure it:
It did.
-Mike
On Tue, 2020-09-08 at 14:19 +0200, Sebastian Andrzej Siewior wrote:
>
> This has nothing to do with the bridge but with the fact that you use a
> non standard queue class (something else than pfifo_fast).
That must be SUSE, I don't muck about in network land. I downloaded a
whole library of RFCs
On 2020-09-08 16:56:20 [+0200], Mike Galbraith wrote:
> On Tue, 2020-09-08 at 14:19 +0200, Sebastian Andrzej Siewior wrote:
> >
> > This has nothing to do with the bridge but with the fact that you use a
> > non standard queue class (something else than pfifo_fast).
>
> That must be SUSE, I don't
On 2020-09-05 07:19:10 [+0200], Mike Galbraith wrote:
> Lappy, which does not use bridge, boots clean... but lock leakage
> pretty darn quickly inspires lockdep to craps its drawers.
>
> [ 209.00] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
> [ 209.001113] turning off the locking correctness
re x360 Convertible/804F, BIOS
> > F.47 11/22/2017
> > [ 209.001118] Call Trace:
> > [ 209.001123] dump_stack+0x77/0x9b
> > [ 209.001129] validate_chain+0xf60/0x1230
>
> I have no idea how to debug this based on this report. Can you narrow
> it down to somethin
On 2020-09-08 17:59:31 [+0200], Mike Galbraith wrote:
> > I have no idea how to debug this based on this report. Can you narrow
> > it down to something?
>
> I instrumented what I presume is still this problem once upon a time,
> structures containing locks are allocated/in
On 2020-09-05 06:47:29 [+0200], Mike Galbraith wrote:
> [ 22.024936] ==
> [ 22.024936] WARNING: possible circular locking dependency detected
> [ 22.024937] 5.9.0.gc70672d-rt3-rt #8 Tainted: GE
> [ 22.024938]
On Tue, 2020-09-08 at 17:06 +0200, Sebastian Andrzej Siewior wrote:
> On 2020-09-08 16:56:20 [+0200], Mike Galbraith wrote:
> > On Tue, 2020-09-08 at 14:19 +0200, Sebastian Andrzej Siewior wrote:
> > >
> > > This has nothing to do with the bridge but with the fact that you use a
> > > non standard
The Kconfig is modified so that the pcie_bus_config setting can be done at
build time in the same manner as the CONFIG_PCIEASPM_ choice. The
pci_bus_config setting may still be overridden by the bootline param.
Signed-off-by: Jim Quinlan
---
drivers/pci/Kconfig | 40
Lappy, which does not use bridge, boots clean... but lock leakage
pretty darn quickly inspires lockdep to craps its drawers.
[ 209.00] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
[ 209.001113] turning off the locking correctness validator.
[ 209.001114] CPU: 2 PID: 3773 Comm: Socket Thread
[ 22.004225] r8169 :03:00.0 eth0: Link is Up - 1Gbps/Full - flow control
off
[ 22.004450] br0: port 1(eth0) entered blocking state
[ 22.004473] br0: port 1(eth0) entered forwarding state
[ 22.006411] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
[ 22.024936]
From: "Rafael J. Wysocki"
Some of the checks done by acpi_hw_read() and acpi_hw_write(),
which are used for accessing GPE registers, are redundant in the
specific case of GPE registers and the ones that are not redundant
can be done upfront at the initialization time so
The conversion time of common DS18B20 clones deviates from
datasheet specs. Allow adjustment and automatic measure of the
conversion time.
Add 'conv_time' sysfs attribute:
*read*: Current conversion time in milliseconds.
*write*:
'0': Set default conversion time.
'1': Measure
On 04/09/2020 17:21:13+0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The time buffer len is used directly in this driver. For readability
> it's better to define a constant.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/rtc/rtc-rx8010.c | 13
From: Bartosz Golaszewski
The time buffer len is used directly in this driver. For readability
it's better to define a constant.
Signed-off-by: Bartosz Golaszewski
---
drivers/rtc/rtc-rx8010.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc
From: Thomas Gleixner
System time snapshots are not conveying information about the current
clocksource which was used, but callers like the PTP KVM guest
implementation have the requirement to evaluate the clocksource type to
select the appropriate mechanism.
Introduce a clocksource id field
On Thu, Sep 03, 2020 at 09:42:32AM +0200, pet...@infradead.org wrote:
> > Maybe I need to explain the reason that why I add two trace point.
> > when using perf tool or Ftrace sysfs to capture the task wake-up latency
> > and the task leaving running queue time, usually the
In order to prevent issues during the firmware to KMS transition, we need
to make sure the pixelvalve are disabled at boot time so that the DRM state
matches the hardware state.
Reviewed-by: Eric Anholt
Tested-by: Chanwoo Choi
Tested-by: Hoegeun Kwon
Tested-by: Stefan Wahren
Signed-off
se ABI. Did
I tell you I utterly hate tracepoints?
> Maybe I need to explain the reason that why I add two trace point.
> when using perf tool or Ftrace sysfs to capture the task wake-up latency and
> the task leaving running queue time, usually the trace data is too large and
> t
t {
> > /* CPU-specific state of this task: */
> > struct thread_struct thread;
> >
> > + /* Task wake up time stamp */
> > + u64 ts_wakeup;
> > + /* Previous task switch out time stamp */
> > + u64
Now that there's no duplication between ISP2400 and ISP2401
input system functions, we can include both at the system
global.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/staging/media/atomisp/pci/input_system_global.h | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git
From: Chris Wilson
[ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
From: Chris Wilson
[ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
From: Chris Wilson
[ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
From: Chris Wilson
[ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
From: Chris Wilson
[ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
From: Chris Wilson
[ Upstream commit a7ef9b28aa8d72a1656fa6f0a01bbd1493886317 ]
Though the number of lock-acquisitions is tracked as unsigned long, this
is passed as the divisor to div_s64() which interprets it as a s32,
giving nonsense values with more than 2 billion acquisitons. E.g.
On Tue, Sep 1, 2020 at 11:32 AM Zeng Tao wrote:
>
> Since commit bd40a175769d ("y2038: itimer: change implementation to
> timespec64")
> we have break the time clamping which handles the potential overflow.
Indeed, good catch!
And I broke it despite the comment tellin
timespec64_to_ns include/linux/time64.h:127 [inline]
set_cpu_itimer+0x65c/0x880 kernel/time/itimer.c:180
do_setitimer+0x8e/0x740 kernel/time/itimer.c:245
__do_sys_setitimer kernel/time/itimer.c:353 [inline]
__se_sys_setitimer kernel/time/itimer.c:336 [inline]
__x64_sys_setitimer+0x14c/0x2c0 kernel/time
Add tracing_on option description to the boot-time tracer.
Signed-off-by: Masami Hiramatsu
---
Documentation/trace/boottime-trace.rst |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/trace/boottime-trace.rst
b/Documentation/trace/boottime-trace.rst
index dcb390075ca1
From: "Paul E. McKenney"
This commit moves the initialization of the CONFIG_PREEMPT=n version of
the rcu_exp_handler() function's rdp and rnp local variables into their
respective declarations to save a couple lines of code.
Signed-off-by: Paul E. McKenney
---
kernel/rcu/tree_exp.h | 6 ++
Add tracing_on option description to the boot-time tracer.
Signed-off-by: Masami Hiramatsu
---
Documentation/trace/boottime-trace.rst |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/trace/boottime-trace.rst
b/Documentation/trace/boottime-trace.rst
index dcb390075ca1
On Sun, Aug 30, 2020 at 1:54 PM Randy Dunlap wrote:
>
> On 8/29/20 1:14 AM, Masahiro Yamada wrote:
> > The next commit will allow users to edit "int", "hex", "string"
> > menus in-place from the data column.
> >
> > The data column should be always displayed.
> >
> > Signed-off-by: Masahiro
On 8/29/20 1:14 AM, Masahiro Yamada wrote:
> The next commit will allow users to edit "int", "hex", "string"
> menus in-place from the data column.
>
> The data column should be always displayed.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> scripts/kconfig/qconf.cc | 29
The next commit will allow users to edit "int", "hex", "string"
menus in-place from the data column.
The data column should be always displayed.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/qconf.cc | 29 +
scripts/kconfig/qconf.h | 5 +
2 files
Thanks peterz, jan
So, enable aio iowait time accounting is a bad idea:(
I gained a lot from you, thanks
-Original Message-
From: pet...@infradead.org [mailto:pet...@infradead.org]
Sent: Friday, August 28, 2020 6:52 PM
To: Jan Kara
Cc: tianxianting (RD) ; v...@zeniv.linux.org.uk;
b
eout()) doesn't account iowait time, so use
> > > this patch to make it to account iowait time, which can truely reflect
> > > the system io situation when using a tool like 'top'.
> >
> > Do be aware though that io_schedule() is potentially far more expensive
&
On Fri 28-08-20 11:07:29, pet...@infradead.org wrote:
> On Fri, Aug 28, 2020 at 02:07:12PM +0800, Xianting Tian wrote:
> > As the normal aio wait path(read_events() ->
> > wait_event_interruptible_hrtimeout()) doesn't account iowait time, so use
> > this patch to make i
On Fri, Aug 28, 2020 at 02:07:12PM +0800, Xianting Tian wrote:
> As the normal aio wait path(read_events() ->
> wait_event_interruptible_hrtimeout()) doesn't account iowait time, so use
> this patch to make it to account iowait time, which can truely reflect
> the system io situa
On Fri 28-08-20 14:07:12, Xianting Tian wrote:
> As the normal aio wait path(read_events() ->
> wait_event_interruptible_hrtimeout()) doesn't account iowait time, so use
> this patch to make it to account iowait time, which can truely reflect
> the system io situation when using a
As the normal aio wait path(read_events() ->
wait_event_interruptible_hrtimeout()) doesn't account iowait time, so use
this patch to make it to account iowait time, which can truely reflect
the system io situation when using a tool like 'top'.
The test result as below.
Test environm
Initialise vdso32_kbase at compile time like vdso64_kbase.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/vdso.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 8f245e988a8a..fb393266b9cb 100644
901 - 1000 of 28833 matches
Mail list logo
