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
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 c173c70ca7d2..6390a37dacea 100644
ount_latch() became the standardized way for seqcount_t
latch read paths. Due to the dependent load, it has one read memory
barrier less than the currently used raw_read_seqcount() API.
Use raw_read_seqcount_latch() for the suspend path.
Commit aadd6e5caaac ("time/sched_clock: Use raw_read
Hi,
Here's a fix for the phy-jz4770 driver, which is broken in 5.9-rc2
starting from commit 2a6c0b82e651 ("USB: PHY: JZ4770: Add support for new
Ingenic SoCs.").
I'm not amused by this, considering that this patch was obviously not
tested, yet it has a Tested-by tag. Next time, please
. Darwish
---
kernel/time/sched_clock.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/sched_clock.c b/kernel/time/sched_clock.c
index 8c6b5febd7a0..0642013dace4 100644
--- a/kernel/time/sched_clock.c
+++ b/kernel/time/sched_clock.c
@@ -35,7 +35,7
kindly ping :)
On Mon, 24 Aug 2020 at 13:20, 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+,
>
From: Thomas Gleixner
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() and convert it to init ops so
that XEN can override it as XEN has it's own PCI/MSI management. The XEN
On Fri, 2020-08-21 at 19:36 +0900, Alexandre Courbot wrote:
> v4l2-compliance expects the driver to adjust the time per frame if it is
> invalid (numerator or denominator set to 0). Adjust it to the default
> value in these cases.
>
Acked-by: Tiffany Lin
> Signed-off-by: Al
On Fri, 2020-08-21 at 19:36 +0900, Alexandre Courbot wrote:
> The time per frame was left initialized to 0/0, which make the driver
> fail v4l2-compliance, and also leaves it potentially exposed to doing a
> division by zero.
>
Acked-by: Tiffany Lin
> Signed-off-by: Al
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+,
|pci_user_read_config_dword() {
|
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
struct thread_structthread;
>
> + /* Task wake up time stamp */
> + u64 ts_wakeup;
> + /* Previous task switch out time stamp */
> + u64 pre_ts_end;
> + /* Next t
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.
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.
, if the threshold is 10 ms, you can run the
following command to only record the scheduling track with the
scheduling delay greater than 10 ms.
echo 'time > 1000' >
/sys/kernel/debug/tracing/events/sched/sched_wakeup_latency/filter
echo 1 > /sys/kernel/debug/tracing/eve
, if the threshold is 10 ms, you can run the
following command to only record the scheduling track with the
scheduling delay greater than 10 ms.
echo 'time > 1000' >
/sys/kernel/debug/tracing/events/sched/sched_wakeup_latency/filter
echo 1 > /sys/kernel/debug/tracing/eve
v4l2-compliance expects the driver to adjust the time per frame if it is
invalid (numerator or denominator set to 0). Adjust it to the default
value in these cases.
Signed-off-by: Alexandre Courbot
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 12
1 file changed, 8
The time per frame was left initialized to 0/0, which make the driver
fail v4l2-compliance, and also leaves it potentially exposed to doing a
division by zero.
Signed-off-by: Alexandre Courbot
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 5 +
1 file changed, 5 insertions
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() and convert it to init ops so
that XEN can override it as XEN has it's own PCI/MSI management. The XEN
override comes in a
On Tue, 18 Aug 2020 13:35:43 +1200, Chris Packham wrote:
> Ensure the OSF flag is cleared on the DS1388 when the clock is set.
Applied, thanks!
[1/1] rtc: ds1307: Clear OSF flag on DS1388 when setting time
commit: f471b05f76e4b1b6ba07ebc7681920a5c5b97c5d
Best regards,
--
Alexan
From: Jakub Kicinski
commit 444da3f52407d74c9aa12187ac6b01f76ee47d62 upstream.
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm
From: Bjorn Helgaas
commit 51c48b310183ab6ba5419edfc6a8de889cc04521 upstream.
pci_bridge_check_ranges() determines whether a bridge supports the optional
I/O and prefetchable memory windows and sets the flag bits in the bridge
resources. This *could* be done once during enumeration except that
On Sun, 9 Aug 2020 13:57:02 +0800, Stanley Chu wrote:
> Fix incorrect calculation of "ms" based waiting time in
> function ufs_mtk_setup_clocks().
Applied to 5.9/scsi-fixes, thanks!
[1/1] scsi: ufs-mediatek: Fix incorrect time to wait link status
https://git.kerne
case mcp794xx:
/*
* these bits were cleared when preparing the date/time
--
2.28.0
From: Jakub Kicinski
commit 444da3f52407d74c9aa12187ac6b01f76ee47d62 upstream.
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm
From: Jakub Kicinski
commit 444da3f52407d74c9aa12187ac6b01f76ee47d62 upstream.
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm
From: Jakub Kicinski
commit 444da3f52407d74c9aa12187ac6b01f76ee47d62 upstream.
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm
From: Jakub Kicinski
commit 444da3f52407d74c9aa12187ac6b01f76ee47d62 upstream.
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm
/kvm/arm/pvtime.rst
index 687b60d..94bffe2 100644
--- a/Documentation/virt/kvm/arm/pvtime.rst
+++ b/Documentation/virt/kvm/arm/pvtime.rst
@@ -3,7 +3,7 @@
Paravirtualized time support for arm64
==
-Arm specification DEN0057/A defines a standard
There is a lock version kvm_write_guest. Use it to simplify code.
Signed-off-by: Keqian Zhu
Reviewed-by: Andrew Jones
Reviewed-by: Steven Price
---
arch/arm64/kvm/pvtime.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/pvtime.c
On 17/08/2020 04:37, Keqian Zhu wrote:
There is a lock version kvm_write_guest. Use it to simplify code.
Signed-off-by: Keqian Zhu
Reviewed-by: Steven Price
---
arch/arm64/kvm/pvtime.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/pvtime.c
insertions(+), 3 deletions(-)
diff --git a/Documentation/virt/kvm/arm/pvtime.rst
b/Documentation/virt/kvm/arm/pvtime.rst
index 687b60d..94bffe2 100644
--- a/Documentation/virt/kvm/arm/pvtime.rst
+++ b/Documentation/virt/kvm/arm/pvtime.rst
@@ -3,7 +3,7 @@
Paravirtualized time support for arm64
e changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/virt/kvm/arm/pvtime.rst
>> b/Documentation/virt/kvm/arm/pvtime.rst
>> index 687b60d..94bffe2 100644
>> --- a/Documentation/virt/kvm/arm/pvtime.rst
>> +++ b/Documentation/virt/kvm/a
On Mon, Aug 17, 2020 at 11:37:29AM +0800, Keqian Zhu wrote:
> There is a lock version kvm_write_guest. Use it to simplify code.
>
> Signed-off-by: Keqian Zhu
> ---
> arch/arm64/kvm/pvtime.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/pvtime.c
/virt/kvm/arm/pvtime.rst
> b/Documentation/virt/kvm/arm/pvtime.rst
> index 687b60d..94bffe2 100644
> --- a/Documentation/virt/kvm/arm/pvtime.rst
> +++ b/Documentation/virt/kvm/arm/pvtime.rst
> @@ -3,7 +3,7 @@
> Paravirtualized time support for arm64
> ==
Allow user space to inform the KVM host what the PV frequency is
and where in the physical memory map the paravirtualized LPT time
structures should be located. User space can set attributes on the
VM for that guest.
The address is given in terms of the physical address visible to
the guest
which contains coefficients that
can be used to map the real counter from the host (the Arm "virtual
counter") to a paravirtualized view of time. On migration the new host
updates the coefficients to ensure that the guests view of time (after
using the coefficients) does
There is no need to hijack initialization procudre to take care of
r4k timer we have CPUHP framework to deal with the CPU plug sequence.
Signed-off-by: Jiaxun Yang
---
arch/mips/include/asm/time.h | 28 +++-
arch/mips/kernel/cevt-r4k.c | 30
There is a lock version kvm_write_guest. Use it to simplify code.
Signed-off-by: Keqian Zhu
---
arch/arm64/kvm/pvtime.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm64/kvm/pvtime.c b/arch/arm64/kvm/pvtime.c
index f7b52ce..2b24e7f 100644
---
--- a/Documentation/virt/kvm/arm/pvtime.rst
+++ b/Documentation/virt/kvm/arm/pvtime.rst
@@ -3,7 +3,7 @@
Paravirtualized time support for arm64
==
-Arm specification DEN0057/A defines a standard for paravirtualised time
+Arm specification DEN0057/A defines
On 8/16/20 7:15 PM, Luc Van Oostenryck wrote:
> On Sun, Aug 16, 2020 at 06:35:26PM -0700, Randy Dunlap wrote:
>>
>> on x86_64, allmodconfig:
>>
>> $ gcc --version
>> gcc (SUSE Linux) 7.5.0
>>
>> $ sparse --version
>> 0.6.2
>>
>>
>
On Sun, Aug 16, 2020 at 06:35:26PM -0700, Randy Dunlap wrote:
>
> on x86_64, allmodconfig:
>
> $ gcc --version
> gcc (SUSE Linux) 7.5.0
>
> $ sparse --version
> 0.6.2
>
>
> I seem to be having some problems with kernel/time/timekeeping.c,
> includ
problems with kernel/time/timekeeping.c,
including a segfault.
a. Is it sparse that segfaults?
b. what prints this message?
make[3]: *** Deleting file 'kernel/time/timekeeping.o'
c. I would prefer to be able to tell the source of warning/error messages,
i.e., gcc or sparse. Especially when they are inter
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
Steve's comment.
Previous series is here:
https://lkml.kernel.org/r/159704847064.175360.3292152056631660862.stgit@devnote2
Thank you,
---
Masami
The time to run dt_binding_check and dtbs_check has gotten
significantly slower as the number of schemas has increased. There's 2
main factors causing validation time on each file to be slow.
The first is python start-up time. This is a common problem for python
without much of a solution
: Ingo Molnar
CommitterDate: Fri, 14 Aug 2020 12:52:35 +02:00
x86/boot: Check that there are no run-time relocations
Add a linker script check that there are no run-time relocations, and
remove the old one that tries to check via looking for specially-named
sections in the object files.
Drop
: Ingo Molnar
CommitterDate: Fri, 14 Aug 2020 12:52:35 +02:00
x86/boot: Remove run-time relocations from .head.text code
The assembly code in head_{32,64}.S, while meant to be
position-independent, generates run-time relocations because it uses
instructions such as:
lealgdt(%edx
: Ingo Molnar
CommitterDate: Fri, 14 Aug 2020 12:52:35 +02:00
x86/boot: Remove run-time relocations from head_{32,64}.S
The BFD linker generates run-time relocations for z_input_len and
z_output_len, even though they are absolute symbols.
This is fixed for binutils-2.35 [1]. Work around
Em Sat, Aug 08, 2020 at 10:31:32AM +0800, Changbin Du escreveu:
> This adds an option '--graph-opts nosleep-time' which allow us
> only to measure on-CPU time. This option is function_graph tracer
> only.
Here an example showing its usage would be great. Even better, on
perf-ftrac
Hi Alexandre,
On Fri, Aug 14, 2020 at 6:15 PM Alexandre Belloni
wrote:
>
> On 14/08/2020 16:10:13+1000, Victor Ding wrote:
> > Hi Alexandre,
> >
> > On Thu, Aug 13, 2020 at 5:33 PM Alexandre Belloni
> > wrote:
> > >
> > > Hi,
> > >
> > > On 13/08/2020 15:41:34+1000, Victor Ding wrote:
> > > >
On 14/08/2020 16:10:13+1000, Victor Ding wrote:
> Hi Alexandre,
>
> On Thu, Aug 13, 2020 at 5:33 PM Alexandre Belloni
> wrote:
> >
> > Hi,
> >
> > On 13/08/2020 15:41:34+1000, Victor Ding wrote:
> > > cmos_read_alarm() may leave certain fields of a struct rtc_time
> > > untouched; therefore,
Hi Alexandre,
On Thu, Aug 13, 2020 at 5:33 PM Alexandre Belloni
wrote:
>
> Hi,
>
> On 13/08/2020 15:41:34+1000, Victor Ding wrote:
> > cmos_read_alarm() may leave certain fields of a struct rtc_time
> > untouched; therefore, these fields contain garbage if not properly
> > initialized, leading
Hi,
On 13/08/2020 15:41:34+1000, Victor Ding wrote:
> cmos_read_alarm() may leave certain fields of a struct rtc_time
> untouched; therefore, these fields contain garbage if not properly
> initialized, leading to inconsistent values when converting into
> time64_t.
> This patch to set all fields
cmos_read_alarm() may leave certain fields of a struct rtc_time
untouched; therefore, these fields contain garbage if not properly
initialized, leading to inconsistent values when converting into
time64_t.
This patch to set all fields of a struct rtc_time to -1 before calling
cmos_read_alarm().
Quoting Viresh Kumar (2020-08-12 01:20:13)
> On 11-08-20, 14:28, Stephen Boyd wrote:
> > @@ -905,7 +907,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned
> > long target_freq)
> >
> > ret = _set_opp_bw(opp_table, NULL, dev, true);
> > if (ret)
> > -
On 11-08-20, 14:28, Stephen Boyd wrote:
> @@ -905,7 +907,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
> target_freq)
>
> ret = _set_opp_bw(opp_table, NULL, dev, true);
> if (ret)
> - return ret;
> + goto
On 8/12/2020 2:58 AM, Stephen Boyd wrote:
We get the opp_table pointer at the top of the function and so we should
put the pointer at the end of the function like all other exit paths
from this function do.
Cc: Rajendra Nayak
Fixes: aca48b61f963 ("opp: Manage empty OPP tables with clk
We get the opp_table pointer at the top of the function and so we should
put the pointer at the end of the function like all other exit paths
from this function do.
Cc: Rajendra Nayak
Fixes: aca48b61f963 ("opp: Manage empty OPP tables with clk handle")
Signed-off-by: Stephen Boyd
---
>
> Fix incorrect calculation of "ms" based waiting time in
> function ufs_mtk_setup_clocks().
>
> Fixes: 9006e3986f66 ("scsi: ufs-mediatek: Do not gate clocks if auto-hibern8
> is
> not entered yet")
> Signed-off-by: Stanley Chu
Reviewed-by: Avri Altman
Committer: Thomas Gleixner
CommitterDate: Mon, 10 Aug 2020 22:14:07 +02:00
time: Delete repeated words in comments
Drop repeated words in kernel/time/. {when, one, into}
Signed-off-by: Randy Dunlap
Signed-off-by: Thomas Gleixner
Acked-by: John Stultz
Link: https://lore.kernel.org/r
From: Nick Desaulniers
Date: Mon, 10 Aug 2020 11:21:11 -0700
> From: Jakub Kicinski
>
> When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> compiler to deduce a case where _val can only have the value of -1 at
> compile time. Specifically,
>
> /*
From: Jakub Kicinski
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm = insn->imm; /* sign extend */
if (imm >> 32) { /* non-
Hi,
This is a series of patches to introduce scripts for the boot-time tracing.
- bconf2ftrace.sh generates a shell script from a bootconfig file which
setup ftrace via tracefs. This is useful for checking whether your
boot-time tracing bootconfig is working as you expected
t; Kernel Mailing List
> > Subject: Re: [PATCH] tools/thermal: tmon: include pthread and time headers
> > in tmon.h
> >
> >
> >
> > On 6/17/2020 4:58 PM, Markus Mayer wrote:
> > > Include sys/time.h and pthread.h in tmon.h, so that types
> > >
Fix incorrect calculation of "ms" based waiting time in
function ufs_mtk_setup_clocks().
Fixes: 9006e3986f66 ("scsi: ufs-mediatek: Do not gate clocks if auto-hibern8 is
not entered yet")
Signed-off-by: Stanley Chu
---
drivers/scsi/ufs/ufs-mediatek.c | 2 +-
1 file change
From: Nick Desaulniers
Date: Thu, 6 Aug 2020 11:29:39 -0700
> From: Jakub Kicinski
>
> When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
> compiler to deduce a case where _val can only have the value of -1 at
> compile time. Specifically,
>
> /*
This adds an option '--graph-opts nosleep-time' which allow us
only to measure on-CPU time. This option is function_graph tracer
only.
Signed-off-by: Changbin Du
---
v3: switch to uniform option --graph-opts.
v2: option name '--nosleep-time' -> '--graph-nosleep-time'.
---
tools/p
On Fri, Aug 07, 2020 at 11:12:29AM -0700, Nick Desaulniers wrote:
> On Fri, Jul 31, 2020 at 4:08 PM Kees Cook wrote:
> >
> > From: Arvind Sankar
> >
> > The BFD linker generates run-time relocations for z_input_len and
> > z_output_len, even
On Fri, Jul 31, 2020 at 4:08 PM Kees Cook wrote:
>
> From: Arvind Sankar
>
> The BFD linker generates run-time relocations for z_input_len and
> z_output_len, even though they are absolute symbols.
>
> This is fixed for binutils-2.35 [1]. Work around this for earlier
>
On Thu, Aug 6, 2020 at 8:32 PM Randy Dunlap wrote:
>
> Drop repeated words in kernel/time/.
> {when, one, into}
>
Acked-by: John Stultz
(I'm sure I'm to blame)
thanks
-john
Drop repeated words in kernel/time/.
{when, one, into}
Signed-off-by: Randy Dunlap
Cc: John Stultz
Cc: Thomas Gleixner
---
kernel/time/alarmtimer.c |2 +-
kernel/time/sched_clock.c |2 +-
kernel/time/timekeeping.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
--- linux
t;> with runnaway IRQs, never has, never will.
> >
> > Getting into the time machine back to the 1990s...
> >
> > DYNIX/ptx had a discretionary mechanism to deal with excessive interrupts.
> > There was a function that long-running interrupt handlers were sup
Paul,
"Paul E. McKenney" writes:
> On Thu, Aug 06, 2020 at 01:45:45PM +0200, pet...@infradead.org wrote:
>> The safety thing is concerned with RT tasks. It doesn't pretend to help
>> with runnaway IRQs, never has, never will.
>
> Getting into the time machine bac
auses it to throttle.
> The further extreme is an interrupt storm, those have always taken a
> machine down.
If every interrupt is actually handled, then yes.
> Accounting unrelated IRQ time to RT tasks is equally wrong, the task
> execution is unrelated to the IRQs. The config optio
From: Jakub Kicinski
When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the
compiler to deduce a case where _val can only have the value of -1 at
compile time. Specifically,
/* struct bpf_insn: _s32 imm */
u64 imm = insn->imm; /* sign extend */
if (imm >> 32) { /* non-
Em Wed, Aug 05, 2020 at 11:34:44AM +0200, Jiri Olsa escreveu:
> Adding tod field to display time of day column with
> time of date (wallclock) time.
>
> # perf record -k CLOCK_MONOTONIC kill
> kill: not enough arguments
> [ perf record: Woken up 1 times to write data ]
Of course.
>
> > And that has nothing to do
> > with a silly test case. Sporadic runaways due to a bug in a once per
> > week code path simply can happen and having the safety net working
> > depending on a config option selected or not is just wrong.
>
> The
g on a config option selected or not is just wrong.
The safety thing is concerned with RT tasks. It doesn't pretend to help
with runnaway IRQs, never has, never will.
The further extreme is an interrupt storm, those have always taken a
machine down.
Accounting unrelated IRQ time to RT tasks is equally w
On 7/3/20 6:51 PM, Daniel Bristot de Oliveira wrote:
> Proposals must be submitted by August 2nd, and submitters will be notified of
> acceptance by August 9th.
Because some people asked for more time to work on their proposals, we ended up
leaving the submission open during this week, post
Em Wed, Aug 05, 2020 at 11:34:42AM +0200, Jiri Olsa escreveu:
> Adding support to convert and store time of day in CTF
> data conversion for 'perf data convert' subcommand.
>
> The perf.data used for conversion needs to have clock data
> information - must be recorded with -k/-
pet...@infradead.org writes:
> On Wed, Aug 05, 2020 at 02:56:49PM +0100, Valentin Schneider wrote:
>
>> I've been tempted to say the test case is a bit bogus, but am not familiar
>> enough with the RT throttling details to stand that ground. That said, from
>> both looking at the execution and the
nclude all system overhead, IRQs, RCU, !RT workqueues etc..
>
> Obviously IRQ_TIME accounting changes the balance a bit, but that's what
> it is. We can't really do anything better.
>
> Apparently this SoC has significant IRQ time for some reason. Also,
> relying on RT throttling
tmar pointed out, CPU and
freq invariant, so falls over on big.LITTLE.
Making update_curr_rt() use rq_clock() rather than rq_clock_task() makes it
"work" but goes against all the good reasons there were to introduce
rq_clock_task() in the first place.
> Apparently this SoC has significant IRQ t
On Wed, Aug 05, 2020 at 02:56:49PM +0100, Valentin Schneider wrote:
> I've been tempted to say the test case is a bit bogus, but am not familiar
> enough with the RT throttling details to stand that ground. That said, from
> both looking at the execution and the stress-ng source code, it seems to
ting changes the balance a bit, but that's what
it is. We can't really do anything better.
Apparently this SoC has significant IRQ time for some reason. Also,
relying on RT throttling for 'correct' behaviour is also wrong. What
needs to be done is find who is using all this RT time and why, that
isn't right.
Adding support to convert and store time of day in CTF
data conversion for 'perf data convert' subcommand.
The perf.data used for conversion needs to have clock data
information - must be recorded with -k/--clockid option).
New --tod option is added to 'perf data convert' subcommand
to convert
Adding tod field to display time of day column with
time of date (wallclock) time.
# perf record -k CLOCK_MONOTONIC kill
kill: not enough arguments
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.033 MB perf.data (8 samples) ]
# perf script
hi,
this patchset is based on changes made by David Ahern long time ago.
The perf code moved a lot since then, but the idea is the same.
The patchset is adding the ability to display TOD/wallclock timestamp
in 'perf script' output and in 'perf data convert --to-ctf' subcommand,
so the converted
t;> 1) When irq accounting is disabled, RT throttling kicks in as
>>>>>> expected.
>>>>>>
>>>>>> 2) With irq accounting the RT throttler does not kick in and the RCU
>>>>>> stall/lockups happen.
>>>>> What is this te
Previously, once we update one block in segment, we will update mtime of
segment to last time, making aged segment becoming freshest, result in
that GC with cost benefit algorithm missing such segment, So this patch
changes to record mtime as average block updating time instead of last
updating
expected.
>>>>>
>>>>> 2) With irq accounting the RT throttler does not kick in and the RCU
>>>>> stall/lockups happen.
>>>> What is this telling us?
>>>
>>> It seems that the fine grained irq time accounting affects the ru
RT throttler does not kick in and the RCU
>>>> stall/lockups happen.
>>> What is this telling us?
>>
>> It seems that the fine grained irq time accounting affects the runtime
>> accounting in some way which I haven't figured out yet.
>>
>
>
; >>> 2) With irq accounting the RT throttler does not kick in and the RCU
> >>> stall/lockups happen.
> >> What is this telling us?
> >
> > It seems that the fine grained irq time accounting affects the runtime
> > accounting in some way which I hav
stall/lockups happen.
>> What is this telling us?
>
> It seems that the fine grained irq time accounting affects the runtime
> accounting in some way which I haven't figured out yet.
>
With IRQ_TIME_ACCOUNTING, rq_clock_task() will always be incremented by a
lesser-or-equal value t
Vladimir Oltean writes:
>> 1) When irq accounting is disabled, RT throttling kicks in as
>> expected.
>>
>> 2) With irq accounting the RT throttler does not kick in and the RCU
>> stall/lockups happen.
>>
>> Not much, but there is clear
1001 - 1100 of 28834 matches
Mail list logo
