On Sun, Dec 06, 2020 at 03:27:01AM +0200, Cristian Ciocaltea wrote:
> Add a new common property 'reset-time-sec' to be used in conjunction
> with the devices supporting the key pressed reset feature.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> Changes in v3:
> - This
On Sun, Dec 06, 2020 at 03:27:01AM +0200, Cristian Ciocaltea wrote:
> Add a new common property 'reset-time-sec' to be used in conjunction
> with the devices supporting the key pressed reset feature.
>
> Signed-off-by: Cristian Ciocaltea
> ---
> Changes in v3:
> - This
g
> > memory usage. Past attempts to optimize runtime at the cost of memory
> > usage were blocked with request for data showing that the optimization
> > made significant improvement for real world scenarios.
> >
> > We have those scenarios now. There have been severa
; usage were blocked with request for data showing that the optimization
> made significant improvement for real world scenarios.
>
> We have those scenarios now. There have been several reports of boot
> time increase in the order of seconds in this thread [1]. Several OEMs
> and
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 Tue, 8 Dec 2020 16:08:02 +0200
Tony Lindgren wrote:
> We have rst_map_012 used for various accelerators like dsp, ipu and iva.
> For these use cases, we have rstctrl bit 2 control the subsystem module
> reset, and have and bits 0 and 1 control the accelerator specific
> features.
>
> If the
both on post-module-load mode changes, as well as at module init
> time, and when run at module init time, it is before register_netdevice()
> has been called and filled in wanted_features. The empty wanted_features
> led to features also getting emptied out, which was definitely not the
&g
We have rst_map_012 used for various accelerators like dsp, ipu and iva.
For these use cases, we have rstctrl bit 2 control the subsystem module
reset, and have and bits 0 and 1 control the accelerator specific
features.
If the bootloader, or kexec boot, has left any accelerator specific
reset
hen NR_IPR > max SGI, it had
> >> > better
> >> > do the check during built time, and associate these related code
> >> > together.
> >> >
> >> > Signed-off-by: Pingfan Liu
> >> > Cc: Catalin Marinas
> >> > Cc: Will De
On 2020-12-08 09:43, Pingfan Liu wrote:
On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
On 2020-12-08 09:21, Pingfan Liu wrote:
> Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> better
> do the check during built time, and associate these related cod
On Tue, Dec 8, 2020 at 5:31 PM Marc Zyngier wrote:
>
> On 2020-12-08 09:21, Pingfan Liu wrote:
> > Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
> > better
> > do the check during built time, and associate these related code
> > together.
&
On 2020-12-08 09:21, Pingfan Liu wrote:
Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had
better
do the check during built time, and associate these related code
together.
Signed-off-by: Pingfan Liu
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas Gleixner
Cc: Jason Coo
Although there is a runtime WARN_ON() when NR_IPR > max SGI, it had better
do the check during built time, and associate these related code together.
Signed-off-by: Pingfan Liu
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Marc Zyngier
Cc: Mark Rutl
From: Leon Romanovsky
Hi,
This is set of various and unrelated fixes that we collected over time.
Thanks
Avihai Horon (1):
RDMA/uverbs: Fix incorrect variable type
Jack Morgenstein (2):
RDMA/core: Clean up cq pool mechanism
RDMA/core: Do not indicate device ready when device enablement
On Tue, 8 Dec 2020 08:26:49 +0900
Masami Hiramatsu wrote:
> Hi Steve,
>
> On Mon, 7 Dec 2020 15:25:40 -0500
> Steven Rostedt wrote:
>
> > On Mon, 7 Dec 2020 23:02:59 +0900
> > Masami Hiramatsu wrote:
> >
> > > There will be the 2 options, one is to change kconfig so that user can not
> >
Hi Steve,
On Mon, 7 Dec 2020 15:25:40 -0500
Steven Rostedt wrote:
> On Mon, 7 Dec 2020 23:02:59 +0900
> Masami Hiramatsu wrote:
>
> > There will be the 2 options, one is to change kconfig so that user can not
> > select FTRACE_STARTUP_TEST if BOOTTIME_TRACING=y, another is to provide
> > a
The PCI subsystem does not currently save and restore the configuration
space for the Precision Time Measurement (PTM) PCIe extended capability
leading to the possibility of the feature returning disabled on S3 resume.
This has been observed on Intel Coffee Lake desktops. Add save/restore
On Mon, 7 Dec 2020 23:02:59 +0900
Masami Hiramatsu wrote:
> There will be the 2 options, one is to change kconfig so that user can not
> select FTRACE_STARTUP_TEST if BOOTTIME_TRACING=y, another is to provide
> a flag from trace_boot and all tests checks the flag at runtime.
> (moreover, that
Hi Steve,
I found that if I enabled the CONFIG_FTRACE_STARTUP_TEST=y and booted the
kernel with kprobe-events defined by boot-time tracing, a warning output.
[ 59.803496] trace_kprobe: Testing kprobe tracing:
[ 59.804258] [ cut here ]
[ 59.805682] WARNING: CPU: 3
Add a new common property 'reset-time-sec' to be used in conjunction
with the devices supporting the key pressed reset feature.
Signed-off-by: Cristian Ciocaltea
---
Changes in v3:
- This patch was not present in v2
Documentation/devicetree/bindings/input/input.yaml | 7 +++
1 file
On Thu, Dec 3, 2020 at 11:45 AM Jakub Kicinski wrote:
...
> nit: let's narrow down the ifdef-enery
>
> no need for the ifdef here, if the helper looks like this:
>
> +static void bond_set_xfrm_features(struct net_device *bond_dev, u64 mode)
> +{
> +#ifdef CONFIG_XFRM_OFFLOAD
> + if (mode ==
Don't try to adjust XFRM support flags if the bond device isn't yet
registered. Bad things can currently happen when netdev_change_features()
is called without having wanted_features fully filled in yet. This code
runs both on post-module-load mode changes, as well as at module init
time, and when
On Thu, 3 Dec 2020 22:14:12 -0500 Jarod Wilson wrote:
> On Thu, Dec 3, 2020 at 11:50 AM Jakub Kicinski wrote:
> >
> > On Wed, 2 Dec 2020 19:43:57 -0500 Jarod Wilson wrote:
> > > bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
> > > -#ifdef CONFIG_XFRM_OFFLOAD
> > > -
> +++ 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 DEN00
On Thu, Dec 3, 2020 at 11:50 AM Jakub Kicinski wrote:
>
> On Wed, 2 Dec 2020 19:43:57 -0500 Jarod Wilson wrote:
> > bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
> > -#ifdef CONFIG_XFRM_OFFLOAD
> > - bond_dev->hw_features |= BOND_XFRM_FEATURES;
> > -#endif /*
saving
> > memory usage. Past attempts to optimize runtime at the cost of memory
> > usage were blocked with request for data showing that the optimization
> > made significant improvement for real world scenarios.
> >
> > We have those scenarios now. There have been
iscrepency gets large enough, it could cause
the time stamps to go backwards when crossing sub buffers, that record a
full 64 bit time stamp, and the new deltas are added to that.
Add a way to validate the events at most events and when crossing a buffer
page. This will help make sure that the deltas
On Wed, 2 Dec 2020 19:43:57 -0500 Jarod Wilson wrote:
> bond_dev->hw_features |= NETIF_F_GSO_ENCAP_ALL | NETIF_F_GSO_UDP_L4;
> -#ifdef CONFIG_XFRM_OFFLOAD
> - bond_dev->hw_features |= BOND_XFRM_FEATURES;
> -#endif /* CONFIG_XFRM_OFFLOAD */
> bond_dev->features |=
post-module-load mode changes, as well as at module init time
> and new bond creation time, and in the latter two scenarios, it is
> running prior to register_netdevice() having been called and
> subsequently filling in wanted_features. The empty wanted_features led
> to features also ge
/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
==
-Arm specification
I did a quick bisect yesterday after noticing that my VMs started
to take 100% cpu time.
Looks like we don't ignore SIPIs that are received while the CPU isn't
waiting for them, and that makes KVM think that CPU always has
pending events which makes it never enter an idle state.
Best regards
including
graphs over time.
Patch 3 kills SIS_AVG_CPU but is partially reintroduced later in the
context of SIS_PROP.
Patch 4 notes that select_idle_core() can find an idle CPU that is
not a free core yet it is ignored and a second search is conducted
in select_idle_cpu
, it is unreasonable to spin here for such extended periods of
time.
To fix this, break the loop down into an outer and an inner loop, and
break out of the inner loop if more than half a second elapsed. To
avoid too much overhead, check for that only every 128 reads, though
there's no particular reason
, it is unreasonable to spin here for such extended periods of
time.
To fix this, break the loop down into an outer and an inner loop, and
break out of the inner loop if more than half a second elapsed. To
avoid too much overhead, check for that only every 128 reads, though
there's no particular reason
, it is unreasonable to spin here for such extended periods of
time.
To fix this, break the loop down into an outer and an inner loop, and
break out of the inner loop if more than half a second elapsed. To
avoid too much overhead, check for that only every 128 reads, though
there's no particular reason
, it is unreasonable to spin here for such extended periods of
time.
To fix this, break the loop down into an outer and an inner loop, and
break out of the inner loop if more than half a second elapsed. To
avoid too much overhead, check for that only every 128 reads, though
there's no particular reason
, it is unreasonable to spin here for such extended periods of
time.
To fix this, break the loop down into an outer and an inner loop, and
break out of the inner loop if more than half a second elapsed. To
avoid too much overhead, check for that only every 128 reads, though
there's no particular reason
When time frequency needs to scale, RDTIME/RDTIMEH instruction in guest
doesn't work correctly. Because it still uses the host's time frequency.
To read correct time, the RDTIME/RDTIMEH instruction executed by guest
should trap to HS-mode. The TM bit of HCOUNTEREN CSR could control whether
This series implements guest time scaling based on RDTIME instruction
emulation so that we can allow migrating Guest/VM across Hosts with
different time frequency.
Why not through para-virt. From arm's experience[1], para-virt implementation
doesn't really solve the problem for the following two
This patch implements KVM_S/GET_ONE_REG of time frequency to support
setting dynamic time frequency from userspace. When the time frequency
specified by userspace is inconsistent with host 'riscv_timebase',
it will use scale_mult and scale_shift to calculate guest scaling time.
Signed-off
Add data path routines required for TX hardware time stamping.
PTP mode is enabled depending on the filter setup (changes tail tag). TX
time stamps are reported via an interrupt / device registers whilst RX
time stamps are reported via an additional tail tag.
One step TX time stamping
Add control routines required for TX hardware time stamping.
The KSZ9563 only supports one step time stamping
(HWTSTAMP_TX_ONESTEP_P2P), which requires linuxptp-2.0 or later.
Currently, only P2P delay measurement is supported. See patchwork
discussion and comments in ksz9477_ptp_init
On Wed, 2 Dec 2020 08:15:02 -0600 Alex Elder wrote:
> Jon Hunter reported observing a build bug in the IPA driver:
>
> https://lore.kernel.org/netdev/5b5d9d40-94d5-5dad-b861-fd9bef826...@nvidia.com
>
> The problem is that the QMB0 max read value set for IPA v4.5 (16) is
> too large to fit in
Don't try to adjust XFRM support flags if the bond device isn't yet
registered. Bad things can currently happen when netdev_change_features()
is called without having wanted_features fully filled in yet. This code
runs on post-module-load mode changes, as well as at module init time
and new bond
s prior message, it sounds
> >> like it's an ordering problem (in that bond_newlink calls
> >> register_netdevice after bond_changelink).
> >
> >Sorry, yeah, this is not actually a race condition, just an ordering
> >issue, bond_check_params() gets called at init tim
link).
>
>Sorry, yeah, this is not actually a race condition, just an ordering
>issue, bond_check_params() gets called at init time, which leads to
>bond_option_mode_set() being called, and does so prior to
>bond_create() running, which is where we actually call
>register_netdevice(
On Wed, Dec 2, 2020 at 2:23 PM Jakub Kicinski wrote:
>
> On Wed, 2 Dec 2020 14:03:53 -0500 Jarod Wilson wrote:
> > On Wed, Dec 2, 2020 at 12:53 PM Jakub Kicinski wrote:
> > >
> > > On Wed, 2 Dec 2020 12:30:53 -0500 Jarod Wilson wrote:
> > > > + if (bond->dev->reg_state != NETREG_REGISTERED)
On 02.12.20 12:57, Frederic Weisbecker wrote:
> account_irq_enter_time() and account_irq_exit_time() are not called
> from modules. EXPORT_SYMBOL_GPL() can be safely removed from the IRQ
> cputime accounting functions called from there.
>
> Signed-off-by: Frederic Weisbecker
> Cc: Peter
t;intended behavior, so prevent that from happening.
>
> Is this an actual race? Reading Ivan's prior message, it sounds
> like it's an ordering problem (in that bond_newlink calls
> register_netdevice after bond_changelink).
Sorry, yeah, this is not actually a race condition, just an ordering
i
Committer: Thomas Gleixner
CommitterDate: Wed, 02 Dec 2020 20:20:05 +01:00
sched/vtime: Consolidate IRQ time accounting
The 3 architectures implementing CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
all have their own version of irq time accounting that dispatch the
cputime to the appropriate index: hardirq
Committer: Thomas Gleixner
CommitterDate: Wed, 02 Dec 2020 20:20:04 +01:00
sched/cputime: Remove symbol exports from IRQ time accounting
account_irq_enter_time() and account_irq_exit_time() are not called
from modules. EXPORT_SYMBOL_GPL() can be safely removed from the IRQ
cputime accounting
On Wed, 2 Dec 2020 14:03:53 -0500 Jarod Wilson wrote:
> On Wed, Dec 2, 2020 at 12:53 PM Jakub Kicinski wrote:
> >
> > On Wed, 2 Dec 2020 12:30:53 -0500 Jarod Wilson wrote:
> > > + if (bond->dev->reg_state != NETREG_REGISTERED)
> > > + goto noreg;
> > > +
> > > if
On Wed, Dec 2, 2020 at 12:53 PM Jakub Kicinski wrote:
>
> On Wed, 2 Dec 2020 12:30:53 -0500 Jarod Wilson wrote:
> > + if (bond->dev->reg_state != NETREG_REGISTERED)
> > + goto noreg;
> > +
> > if (newval->value == BOND_MODE_ACTIVEBACKUP)
> >
like it's an ordering problem (in that bond_newlink calls
register_netdevice after bond_changelink).
The change to bond_option_mode_set tests against reg_state, so
presumably it wants to skip the first(?) time through, before the
register_netdevice call; is that right?
-J
>Origi
On Wed, 2 Dec 2020 12:30:53 -0500 Jarod Wilson wrote:
> + if (bond->dev->reg_state != NETREG_REGISTERED)
> + goto noreg;
> +
> if (newval->value == BOND_MODE_ACTIVEBACKUP)
> bond->dev->wanted_features |= BOND_XFRM_FEATURES;
> else
>
On Wed, 2 Dec 2020 12:30:53 -0500
Jarod Wilson wrote:
> Don't try to adjust XFRM support flags if the bond device isn't yet
> registered. Bad things can currently happen when netdev_change_features()
> is called without having wanted_features fully filled in yet. Basically,
> this code was
Don't try to adjust XFRM support flags if the bond device isn't yet
registered. Bad things can currently happen when netdev_change_features()
is called without having wanted_features fully filled in yet. Basically,
this code was racing against register_netdevice() filling in
wanted_features, and
Jon Hunter reported observing a build bug in the IPA driver:
https://lore.kernel.org/netdev/5b5d9d40-94d5-5dad-b861-fd9bef826...@nvidia.com
The problem is that the QMB0 max read value set for IPA v4.5 (16) is
too large to fit in the 4-bit field.
The actual value we want is 0, which requests
The 3 architectures implementing CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
all have their own version of irq time accounting that dispatch the
cputime to the appropriate index: hardirq, softirq, system, idle,
guest... from an all-in-one function.
Instead of having these ad-hoc versions, move the cputime
Slightly different design this time. As per Peter and Thomas reviews and
suggestions, use the following layout:
account_softirq_enter() -> irqtime_account_irq(curr, SOFTIRQ_OFFSET);
account_softirq_exit() -> irqtime_account_irq(curr, 0);
account_hardirq_enter() -> irqtime_ac
account_irq_enter_time() and account_irq_exit_time() are not called
from modules. EXPORT_SYMBOL_GPL() can be safely removed from the IRQ
cputime accounting functions called from there.
Signed-off-by: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Michael Ellerman
Cc:
Jon Hunter reported observing a build bug in the IPA driver:
https://lore.kernel.org/netdev/5b5d9d40-94d5-5dad-b861-fd9bef826...@nvidia.com
The problem is that the QMB0 max read value set for IPA v4.5 (16) is
too large to fit in the 4-bit field.
This is a quick fix to resolve the build bug;
Add data path routines required for TX hardware time stamping.
PTP mode is enabled depending on the filter setup (changes tail tag). TX
time stamps are reported via an interrupt / device registers whilst RX
time stamps are reported via an additional tail tag.
One step TX time stamping
Add control routines required for TX hardware time stamping.
The KSZ9563 only supports one step time stamping
(HWTSTAMP_TX_ONESTEP_P2P), which requires linuxptp-2.0 or later.
Currently, only P2P delay measurement is supported. See patchwork
discussion and comments in ksz9477_ptp_init
From: Benjamin Berg
[ Upstream commit e40cc1b476d60f22628741e53cf3446a29e6e6b9 ]
The lid state may change while the machine is suspended. As such, we may
need to re-check the state at wake-up time (at least when waking up from
hibernation).
Add the appropriate call to the resume handler
From: Vladimir Oltean
[ Upstream commit 90cf87d16bd566cff40c2bc8e32e6d4cd3af23f0 ]
The tc-taprio base time indicates the beginning of the tc-taprio
schedule, which is cyclic by definition (where the length of the cycle
in nanoseconds is called the cycle time). The base time is a 64-bit PTP
time
From: Benjamin Berg
[ Upstream commit e40cc1b476d60f22628741e53cf3446a29e6e6b9 ]
The lid state may change while the machine is suspended. As such, we may
need to re-check the state at wake-up time (at least when waking up from
hibernation).
Add the appropriate call to the resume handler
From: Benjamin Berg
[ Upstream commit e40cc1b476d60f22628741e53cf3446a29e6e6b9 ]
The lid state may change while the machine is suspended. As such, we may
need to re-check the state at wake-up time (at least when waking up from
hibernation).
Add the appropriate call to the resume handler
It takes some significant time between when we ask the EC to enable the
DCON power and when we can access the DCON registers.
FIXME: Maybe some of the delay is caused on the DCON side once the power
is good. Need to check with a scope I suppose.
Signed-off-by: Lubomir Rintel
---
drivers
The 3 architectures implementing CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
all have their own version of irq time accounting that dispatch the
cputime to the appropriate index: hardirq, softirq, system, idle,
guest... from an all-in-one function.
Instead of having these ad-hoc versions, move the cputime
account_irq_enter_time() and account_irq_exit_time() are not called
from modules. EXPORT_SYMBOL_GPL() can be safely removed from the IRQ
cputime accounting functions called from there.
Signed-off-by: Frederic Weisbecker
Cc: Peter Zijlstra
Cc: Tony Luck
Cc: Fenghua Yu
Cc: Michael Ellerman
Cc:
In this version, the EXPORT_SYMBOL_GPL() on IRQ time accounting have
been removed since no modules should be calling there.
Link to v1 for reference:
https://lore.kernel.org/lkml/20201125021542.30237-1-frede...@kernel.org/
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux
s390 has its own version of IRQ time accounting because it doesn't
account the idle time the same way the other architectures do. Only
the actual idle sleep time is accounted as idle time, the rest of the
idle task execution is accounted as system time.
However converting it to the consolidated
Change aggr_time_limit_encoded() to properly calculate the
aggregation time limit to use for IPA v4.5.
Older IPA versions program the AGGR_GRANULARITY field of the
of the COUNTER_CFG register to set the granularity of the
aggregation timer, which we configure to be 500 microseconds.
Instead, IPA
ct ipa *ipa, u32 microseconds)
+{
+ u32 gran_sel;
+ u32 val;
+
+ /* IPA v4.5 expresses time limits using Qtime. The AP has
+* pulse generators 0 and 1 available, which were configured
+* in ipa_qtime_config() to have granularity 100 usec and
+* 1 msec, respec
The 10 delay_us of the poll on the GICR_VPENDBASER.Dirty bit is too
high, which might greatly affect the total scheduling latency of a
vCPU in our measurement. So we reduce it to 1 to lessen the impact.
Signed-off-by: Shenming Lu
---
drivers/irqchip/irq-gic-v3-its.c | 2 +-
1 file changed, 1
ar test
> case.
>
> Due to the internal implementation of ktime_get_real_seconds(), which is
> a 2038 safe replacement for the former get_seconds() function, this
> accumulation issue can be observed. (time(2) via syscall and newer
> versions of VDSO use the same mechanism).
>
>
On Nov 25 2020, Carlos O'Donell via Libc-alpha wrote:
> We might write a syscall interception framework using seccomp
> and SECCOMP_RET_TRACE, but that involves ptrace'ing the process
> under test, and is equivalent to a micro-sandbox. I'm not against
> that idea for testing; we would test what
On 11/25/20 7:17 PM, Thomas Gleixner wrote:
> Carlos, Petr,
>
> On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
>> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>>> So from my point of view asking for distorted time still _is_ a request
>>> for ponies.
>>
Carlos, Petr,
On Wed, Nov 25 2020 at 15:37, Carlos O'Donell wrote:
> On 11/19/20 7:14 PM, Thomas Gleixner wrote:
>> So from my point of view asking for distorted time still _is_ a request
>> for ponies.
>
> I'm happy if you say it's more work than the value it provides.
On 11/19/20 7:14 PM, Thomas Gleixner wrote:
> I hope you are aware that the time namespace offsets have to be set
> _before_ the process starts and can't be changed afterwards,
> i.e. settime() is not an option.
I not interested in settime(). I saw Petr's request and forwarded i
on by distros (*cough*) and comes with a description that any
bug reports against it vs. time correctness are going to be ignored.
Yes. I would be requiring CONFIG_DEBUG_DISTORTED_CLOCK_REALTIME.
Let me be clear though, the distros have *+debug kernels for which this
CONFIG_DEBUG_* could get turned
: Peter Zijlstra
CommitterDate: Tue, 24 Nov 2020 16:47:48 +01:00
sched: Limit the amount of NUMA imbalance that can exist at fork time
At fork time currently, a local node can be allowed to fill completely
and allow the periodic load balancer to fix the problem. This can be
problematic in cases
: Peter Zijlstra
CommitterDate: Tue, 24 Nov 2020 16:47:47 +01:00
sched: Avoid unnecessary calculation of load imbalance at clone time
In find_idlest_group(), the load imbalance is only relevant when the group
is either overloaded or fully busy but it is calculated unconditionally.
This patch moves
Hi!
> This is a general problem and not really just for this particular test
> case.
>
> Due to the internal implementation of ktime_get_real_seconds(), which is
> a 2038 safe replacement for the former get_seconds() function, this
> accumulation issue can be observed. (t
?
See below.
>> This shmctl01 test detect the time as the number of seconds twice
>> (before and after) the shmget() instruction, then it verifies
>> whether the 'struct shmid_ds ds' gets data correctly. But here it
>> shows 'ds->ctime' out of the seconds range (1604298586, 160429
On Tue, Nov 24, 2020 at 08:46:38PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> When wakeup signaling is enabled for a bridge for the second (or every
> next) time in a row, its existing device wakeup power configuration
> may not match the new conditions. Fo
The 3 architectures implementing CONFIG_VIRT_CPU_ACCOUNTING_NATIVE
all have their own version of irq time accounting that dispatch the
cputime to the appropriate index: hardirq, softirq, system, idle,
guest... from an all-in-one function.
Instead of having these ad-hoc versions, move the cputime
that thoroughly).
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
irq/core
HEAD: 9502ee20aed8bb847176e1d7d83ccd0625430744
Frederic Weisbecker (4):
sched/vtime: Consolidate IRQ time accounting
s390/vtime: Convert to consolidated IRQ time accounting
irqtime: Move irqtime
s390 has its own version of IRQ time accounting because it doesn't
account the idle time the same way the other architectures do. Only
the actual idle sleep time is accounted as idle time, the rest of the
idle task execution is accounted as system time.
However converting it to the consolidated
From: Rafael J. Wysocki
When wakeup signaling is enabled for a bridge for the second (or every
next) time in a row, its existing device wakeup power configuration
may not match the new conditions. For example, some devices below
it may have been put into low-power states and that changes
saving
> > memory usage. Past attempts to optimize runtime at the cost of memory
> > usage were blocked with request for data showing that the optimization
> > made significant improvement for real world scenarios.
> >
> > We have those scenarios now. There have been
were blocked with request for data showing that the optimization
> made significant improvement for real world scenarios.
>
> We have those scenarios now. There have been several reports of boot
> time increase in the order of seconds in this thread [1]. Several OEMs
> and SoC manufacturers h
a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jarod-Wilson/bonding-fix-feature-flag-setting-at-init-time/20201123-111956
base: https://git.kernel.org/pub/scm/linux/kernel/git
On Sun, 22 Nov 2020 22:17:16 -0500
Jarod Wilson wrote:
> Have run into a case where bond_option_mode_set() gets called before
> hw_features has been filled in, and very bad things happen when
> netdev_change_features() then gets called, because the empty hw_features
> wipes out almost all
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 a/drivers
Have run into a case where bond_option_mode_set() gets called before
hw_features has been filled in, and very bad things happen when
netdev_change_features() then gets called, because the empty hw_features
wipes out almost all features. Further reading of netdev feature flag
documentation suggests
On Thu, 12 Nov 2020 12:20:48 +0100, Oleksij Rempel wrote:
> According to the TI application bulletin [1] we deal with two generic
> mechanisms which would affect the precision of provided input events:
>
> |TOUCH SCREEN SETTLING TIME
> |
> |When the touch panel is
significant improvement for real world scenarios.
We have those scenarios now. There have been several reports of boot
time increase in the order of seconds in this thread [1]. Several OEMs
and SoC manufacturers have also privately reported significant
(350-400ms) increase in boot time due to all the parsing
On Wed, Nov 18, 2020 at 09:30:10PM +0100, Christian Eggers wrote:
> Add control routines required for TX hardware time stamping.
>
> The KSZ9563 only supports one step time stamping
> (HWTSTAMP_TX_ONESTEP_P2P), which requires linuxptp-2.0 or later.
>
> Currently, only P2P
501 - 600 of 28833 matches
Mail list logo
