Hi Steve,
Can you review this series? Especially, [07/36] and [12/36] has been changed
a lot from your original patch.
Thank you,
On Mon, 15 Apr 2024 21:48:59 +0900
"Masami Hiramatsu (Google)" wrote:
> Hi,
>
> Here is the 9th version of the series to re-implement the fprobe on
>
On Thu, 18 Apr 2024 09:55:55 +0300
Mike Rapoport wrote:
Hi Mike,
Thanks for doing this review!
> > +/**
> > + * struct trace_buffer_meta - Ring-buffer Meta-page description
> > + * @meta_page_size:Size of this meta-page.
> > + * @meta_struct_len: Size of this structure.
> > + *
On Tue, 16 Apr 2024 22:41:01 +
Beau Belgrave wrote:
> When the ABI was updated to prevent same name w/different args, it
> missed an important corner case when fields don't end with a space.
> Typically, space is used for fields to help separate them, like
> "u8 field1; u8 field2". If no
On Fri, Apr 19, 2024 at 7:26 AM Jason Xing wrote:
>
> > When I said "If you feel the need to put them in a special group, this
> > is fine by me.",
> > this was really about partitioning the existing enum into groups, if
> > you prefer having a group of 'RES reasons'
>
> Are you suggesting
When a CPU is offline, its IRQs may migrate to other CPUs. For managed
IRQs, they are migrated, or shutdown (if all CPUs of the managed IRQ
affinity are offline). For regular IRQs, there will only be a migration.
The migrate_one_irq() first uses pending_mask or affinity_mask of the IRQ.
104
Please refer to the commit message of the patch for details.
The cover letter is to demonstrate how to reproduce the issue on purpose with
QEMU/KVM + virtio-net (that's why virtualizat...@lists.linux.dev is CCed).
Thank you very much!
1. Build the mainline linux
On 16/04/2024 3:20 pm, Haitao Huang wrote:
From: Kristen Carlson Accardi
In cases EPC pages need be allocated during a page fault and the cgroup
usage is near its limit, an asynchronous reclamation needs be triggered
to avoid blocking the page fault handling.
Create a workqueue,
On Thu, 18 Apr 2024 12:09:09 -0700
Andrii Nakryiko wrote:
> Take into account CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING when validating
> that RCU is watching when trying to setup rethooko on a function entry.
>
> One notable exception when we force rcu_is_watching() check is
>
On Thu, 18 Apr 2024 12:10:59 +0100
Jonthan Haslam wrote:
> Hi Masami,
>
> > > > OK, then I'll push this to for-next at this moment.
> > > > Please share if you have a good idea for the batch interface which can
> > > > be
> > > > backported. I guess it should involve updating userspace changes
Hello RT-list!
I'm pleased to announce the 5.10.215-rt107 stable release.
This release is simply an update to the new stable 5.10.215 version and no
RT-specific changes have been performed.
You can get this release via the git tree at:
Was requested by Jarkko:
https://lore.kernel.org/lkml/CYU504RLY7QU.QZY9LWC076NX@suppilovahvero/#t
[...]
Ah I missed that. No problem to me.
--- /dev/null
+++ b/arch/x86/kernel/cpu/sgx/epc_cgroup.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _SGX_EPC_CGROUP_H_
> When I said "If you feel the need to put them in a special group, this
> is fine by me.",
> this was really about partitioning the existing enum into groups, if
> you prefer having a group of 'RES reasons'
Are you suggesting copying what we need from enum skb_drop_reason{} to
enum
On Thu, Apr 18, 2024 at 12:09:09PM -0700, Andrii Nakryiko wrote:
> Take into account CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING when validating
> that RCU is watching when trying to setup rethooko on a function entry.
>
> One notable exception when we force rcu_is_watching() check is
>
On Sat, Apr 13, 2024 at 08:48:57AM -0400, Steven Rostedt wrote:
> On Sat, 13 Apr 2024 12:53:38 +0200
> Peter Zijlstra wrote:
>
> > On Fri, Apr 12, 2024 at 09:37:24AM -0700, Beau Belgrave wrote:
> >
> > > > Anyway, since we typically run stuff from NMI context, accessing user
> > > > data is
On Tue, 16 Apr 2024 08:22:06 -0500, Huang, Kai wrote:
On Mon, 2024-04-15 at 20:20 -0700, Haitao Huang wrote:
From: Kristen Carlson Accardi
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The
existing
On Fri, Apr 19, 2024 at 6:29 AM Jason Xing wrote:
>
> On Fri, Apr 19, 2024 at 2:51 AM Eric Dumazet wrote:
> >
> > On Thu, Apr 18, 2024 at 6:24 PM Jason Xing
> > wrote:
> > >
> > > On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> > > >
> > > > On Thu, 18 Apr 2024 11:30:02 +0800 Jason
On Fri, Apr 19, 2024 at 2:51 AM Eric Dumazet wrote:
>
> On Thu, Apr 18, 2024 at 6:24 PM Jason Xing wrote:
> >
> > On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> > >
> > > On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > > > I'm not sure why the patch series has been changed to
AMD-Xilinx Versal platform is successor of ZynqMP platform.
Real-time Processing Unit R5 cluster IP on Versal is same as
of ZynqMP Platform. Power-domains ids for Versal platform is
different than ZynqMP.
AMD-Xilinx Versal-NET platform is successor of Versal platform.
Versal-NET Real-Time
On Thu, Apr 18, 2024 at 10:54 AM Mike Rapoport wrote:
>
> On Thu, Apr 18, 2024 at 09:13:27AM -0700, Song Liu wrote:
> > On Thu, Apr 18, 2024 at 8:37 AM Mike Rapoport wrote:
> > > > >
> > > > > I'm looking at execmem_types more as definition of the consumers,
> > > > > maybe I
> > > > > should
Hello RT-list!
I'm pleased to announce the 5.10.214-rt106 stable release.
This release is simply an update to the new stable 5.10.214 version and no
RT-specific changes have been performed.
You can get this release via the git tree at:
On Thu, Apr 18, 2024, Will Deacon wrote:
> On Mon, Apr 15, 2024 at 10:03:51AM -0700, Sean Christopherson wrote:
> > On Sat, Apr 13, 2024, Marc Zyngier wrote:
> > > On Fri, 12 Apr 2024 15:54:22 +0100, Sean Christopherson
> > > wrote:
> > > >
> > > > On Fri, Apr 12, 2024, Marc Zyngier wrote:
> >
On Thu, Apr 18, 2024 at 10:31:16PM +0300, Nadav Amit wrote:
>
> > On 18 Apr 2024, at 13:20, Mike Rapoport wrote:
> >
> > On Tue, Apr 16, 2024 at 12:36:08PM +0300, Nadav Amit wrote:
> >>
> >>
> >>
> >> I might be missing something, but it seems a bit racy.
> >>
> >> IIUC, module_finalize()
> On 18 Apr 2024, at 13:20, Mike Rapoport wrote:
>
> On Tue, Apr 16, 2024 at 12:36:08PM +0300, Nadav Amit wrote:
>>
>>
>>
>> I might be missing something, but it seems a bit racy.
>>
>> IIUC, module_finalize() calls alternatives_smp_module_add(). At this
>> point, since you don’t hold the
Take into account CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING when validating
that RCU is watching when trying to setup rethooko on a function entry.
One notable exception when we force rcu_is_watching() check is
CONFIG_KPROBE_EVENTS_ON_NOTRACE=y case, in which case kretprobes will use
old-style
Introduce CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING config option to
control whether ftrace low-level code performs additional
rcu_is_watching()-based validation logic in an attempt to catch noinstr
violations.
This check is expected to never be true and is mostly useful for
low-level validation of
On Thu, Apr 18, 2024 at 6:24 PM Jason Xing wrote:
>
> On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
> >
> > On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > > I'm not sure why the patch series has been changed to 'Changes
> > > Requested', until now I don't think I need to
On Tue, Apr 9, 2024 at 3:48 PM Masami Hiramatsu wrote:
>
> On Wed, 3 Apr 2024 15:03:28 -0700
> Andrii Nakryiko wrote:
>
> > Take into account CONFIG_FTRACE_VALIDATE_RCU_IS_WATCHING when validating
> > that RCU is watching when trying to setup rethooko on a function entry.
> >
> > This further
On Mon, Apr 15, 2024 at 1:25 AM Jiri Olsa wrote:
>
> On Tue, Apr 02, 2024 at 11:33:00AM +0200, Jiri Olsa wrote:
>
> SNIP
>
> > #include
> > #include
> > @@ -308,6 +309,88 @@ static int uprobe_init_insn(struct arch_uprobe
> > *auprobe, struct insn *insn, bool
> > }
> >
> > #ifdef
On Thu, Apr 18, 2024 at 8:50 PM Aren wrote:
> On Thu, Apr 18, 2024 at 06:56:09PM +0300, Andy Shevchenko wrote:
> > On Thu, Apr 18, 2024 at 6:06 PM Aren wrote:
> > > On Mon, Apr 15, 2024 at 05:04:53PM +0300, Andy Shevchenko wrote:
> > > > On Sun, Apr 14, 2024 at 8:57 PM Aren Moynihan
> > > >
On Thu, Apr 18, 2024 at 09:13:27AM -0700, Song Liu wrote:
> On Thu, Apr 18, 2024 at 8:37 AM Mike Rapoport wrote:
> > > >
> > > > I'm looking at execmem_types more as definition of the consumers, maybe
> > > > I
> > > > should have named the enum execmem_consumer at the first place.
> > >
> > > I
On Thu, Apr 18, 2024 at 06:56:09PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 18, 2024 at 6:06 PM Aren wrote:
> > On Mon, Apr 15, 2024 at 05:04:53PM +0300, Andy Shevchenko wrote:
> > > On Sun, Apr 14, 2024 at 8:57 PM Aren Moynihan
> > > wrote:
>
> ...
>
> > > >
On Thu, Apr 18, 2024 at 11:46 PM Jakub Kicinski wrote:
>
> On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> > I'm not sure why the patch series has been changed to 'Changes
> > Requested', until now I don't think I need to change something.
> >
> > Should I repost this series (keeping the
On Thu, Apr 18, 2024 at 8:37 AM Mike Rapoport wrote:
>
[...]
> >
> > Is +/- 2G enough for all realistic use cases? If so, I guess we don't
> > really need
> > EXECMEM_ANYWHERE below?
> >
> > > >
> > > > * I'm not sure about BPF's requirements; it seems happy doing the same
> > > > as
> > > >
On Thu, Apr 18, 2024 at 6:06 PM Aren wrote:
> On Mon, Apr 15, 2024 at 05:04:53PM +0300, Andy Shevchenko wrote:
> > On Sun, Apr 14, 2024 at 8:57 PM Aren Moynihan
> > wrote:
...
> > > stk3310_set_state(iio_priv(indio_dev), STK3310_STATE_STANDBY);
> > > + if (data->vdd_reg)
> > > +
On Thu, 18 Apr 2024 11:30:02 +0800 Jason Xing wrote:
> I'm not sure why the patch series has been changed to 'Changes
> Requested', until now I don't think I need to change something.
>
> Should I repost this series (keeping the v6 tag) and then wait for
> more comments?
If Eric doesn't like it
Hi Masami,
On Thu, Apr 18, 2024 at 06:16:15AM +0900, Masami Hiramatsu wrote:
> Hi Mike,
>
> On Thu, 11 Apr 2024 19:00:50 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (IBM)"
> >
> > kprobes depended on CONFIG_MODULES because it has to allocate memory for
> > code.
> >
> > Since
On Wed, Apr 17, 2024 at 04:32:49PM -0700, Song Liu wrote:
> On Tue, Apr 16, 2024 at 12:23 AM Mike Rapoport wrote:
> >
> > On Mon, Apr 15, 2024 at 06:36:39PM +0100, Mark Rutland wrote:
> > > On Mon, Apr 15, 2024 at 09:52:41AM +0200, Peter Zijlstra wrote:
> > > > On Thu, Apr 11, 2024 at 07:00:41PM
On Mon, Apr 15, 2024 at 05:04:53PM +0300, Andy Shevchenko wrote:
> On Sun, Apr 14, 2024 at 8:57 PM Aren Moynihan wrote:
> >
> > From: Ondrej Jirman
> >
> > VDD power input can be used to completely power off the chip during
> > system suspend. Do so if available.
>
> ...
>
> > #include
> >
On Thu, Apr 18, 2024 at 3:23 PM Julian Anastasov wrote:
>
>
> Hello,
Dear Julian,
>
> On Thu, 18 Apr 2024, Alexander Mikhalitsyn wrote:
>
> > Cc: Julian Anastasov
> > Cc: Simon Horman
> > Cc: Pablo Neira Ayuso
> > Cc: Jozsef Kadlecsik
> > Cc: Florian Westphal
> > Suggested-by:
Let's make all IPVS sysctls writtable even when
network namespace is owned by non-initial user namespace.
Let's make a few sysctls to be read-only for non-privileged users:
- sync_qlen_max
- sync_sock_size
- run_estimation
- est_cpulist
- est_nice
I'm trying to be conservative with this to
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Suggested-by: Julian Anastasov
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git
It was observed in the wild that pairs of consecutive packets would leave
the IPVS with the same wrong checksum, and the issue only went away when
disabling GSO.
IPVS needs to avoid computing the SCTP checksum when using GSO.
Co-developed-by: Firo Yang
Signed-off-by: Ismael Luceno
Tested-by:
On Mon, Apr 15, 2024 at 10:03:51AM -0700, Sean Christopherson wrote:
> On Sat, Apr 13, 2024, Marc Zyngier wrote:
> > On Fri, 12 Apr 2024 15:54:22 +0100, Sean Christopherson
> > wrote:
> > >
> > > On Fri, Apr 12, 2024, Marc Zyngier wrote:
> > > > On Fri, 12 Apr 2024 11:44:09 +0100, Will Deacon
From: Jason Xing
At last, we should let it work by introducing this reset reason in
trace world.
One of the possible expected outputs is:
... tcp_send_reset: skbaddr=xxx skaddr=xxx src=xxx dest=xxx
state=TCP_ESTABLISHED reason=NOT_SPECIFIED
Signed-off-by: Jason Xing
Reviewed-by: Steven
From: Jason Xing
Since we have mapped every mptcp reset reason definition
in enum sk_rst_reason, introducing a new helper can cover
some missing places where we have already set the
subflow->reset_reason.
Note: using SK_RST_REASON_NOT_SPECIFIED is the same as
SK_RST_REASON_MPTCP_RST_EUNSPEC.
From: Jason Xing
It relys on what reset options in the skb are as rfc8684 says. Reusing
this logic can save us much energy. This patch replaces most of the prior
NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/mptcp/subflow.c | 22 +-
1 file changed, 17
From: Jason Xing
Reuse the dropreason logic to show the exact reason of tcp reset,
so we don't need to implement those duplicated reset reasons.
This patch replaces all the prior NOT_SPECIFIED reasons.
Signed-off-by: Jason Xing
---
net/ipv4/tcp_ipv4.c | 8
net/ipv6/tcp_ipv6.c | 8
From: Jason Xing
Like what we did to passive reset:
only passing possible reset reason in each active reset path.
No functional changes.
Signed-off-by: Jason Xing
---
include/net/tcp.h | 3 ++-
net/ipv4/tcp.c| 15 ++-
net/ipv4/tcp_output.c | 3 ++-
From: Jason Xing
Adjust the parameter and support passing reason of reset which
is for now NOT_SPECIFIED. No functional changes.
Signed-off-by: Jason Xing
---
include/net/request_sock.h | 4 +++-
net/dccp/ipv4.c| 10 ++
net/dccp/ipv6.c| 10 ++
From: Jason Xing
Add a new standalone file for the easy future extension to support
both active reset and passive reset in the TCP/DCCP/MPTCP protocols.
This patch only does the preparations for reset reason mechanism,
nothing else changes.
The reset reasons are divided into three parts:
1)
From: Jason Xing
In production, there are so many cases about why the RST skb is sent but
we don't have a very convenient/fast method to detect the exact underlying
reasons.
RST is implemented in two kinds: passive kind (like tcp_v4_send_reset())
and active kind (like tcp_send_active_reset()).
This reverts commit b5085b5ac1d96ea2a8a6240f869655176ce44197.
The change has an incorrect assumption about the return value because
in the current stable trees for versions 5.15 and before, the following
commit responsible for making 0 a success value is not present:
b8cc44a4d3c1 ("tracing:
Hello,
On Thu, 18 Apr 2024, Alexander Mikhalitsyn wrote:
> Cc: Julian Anastasov
> Cc: Simon Horman
> Cc: Pablo Neira Ayuso
> Cc: Jozsef Kadlecsik
> Cc: Florian Westphal
> Suggested-by: Julian Anastasov
> Signed-off-by: Alexander Mikhalitsyn
> ---
>
On Thu, Apr 18, 2024 at 09:04:53AM +0200, Thorsten Leemhuis wrote:
> On 17.04.24 15:38, Greg KH wrote:
> > On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> >> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> >>> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni :
On Wed, 17 Apr 2024 15:18:22 +0800 you wrote:
> The RSS hash report is a feature that's part of the virtio specification.
> Currently, virtio backends like qemu, vdpa (mlx5), and potentially vhost
> (still a work in
On 18.04.24 08:26, zhenwei pi wrote:
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change
On 18.04.24 08:26, zhenwei pi wrote:
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 20
Hi Masami,
> > > OK, then I'll push this to for-next at this moment.
> > > Please share if you have a good idea for the batch interface which can be
> > > backported. I guess it should involve updating userspace changes too.
> >
> > Did you (or anyone else) need anything more from me on this one
Let's make all IPVS sysctls writtable even when
network namespace is owned by non-initial user namespace.
Let's make a few sysctls to be read-only for non-privileged users:
- sync_qlen_max
- sync_sock_size
- run_estimation
- est_cpulist
- est_nice
I'm trying to be conservative with this to
On Wed, Apr 17, 2024 at 3:02 PM Julian Anastasov wrote:
>
>
> Hello,
Dear Julian,
>
> On Tue, 16 Apr 2024, Alexander Mikhalitsyn wrote:
>
> > Let's make all IPVS sysctls visible and RO even when
> > network namespace is owned by non-initial user namespace.
> >
> > Let's make a few
Cc: Julian Anastasov
Cc: Simon Horman
Cc: Pablo Neira Ayuso
Cc: Jozsef Kadlecsik
Cc: Florian Westphal
Suggested-by: Julian Anastasov
Signed-off-by: Alexander Mikhalitsyn
---
net/netfilter/ipvs/ip_vs_ctl.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git
On 18.04.24 08:26, zhenwei pi wrote:
When the guest OS runs under critical memory pressure, the guest
starts to kill processes. A guest monitor agent may scan 'oom_kill'
from /proc/vmstat, and reports the OOM KILL event. However, the agent
may be killed and we will loss this critical event(and
On Tue, Apr 16, 2024 at 09:52:34AM +0200, Peter Zijlstra wrote:
> On Mon, Apr 15, 2024 at 08:00:26PM +0300, Mike Rapoport wrote:
> > On Mon, Apr 15, 2024 at 12:47:50PM +0200, Peter Zijlstra wrote:
> > > On Thu, Apr 11, 2024 at 07:05:25PM +0300, Mike Rapoport wrote:
> > >
> > > > To populate the
On Tue, Apr 16, 2024 at 12:36:08PM +0300, Nadav Amit wrote:
>
>
> > On 11 Apr 2024, at 19:05, Mike Rapoport wrote:
> >
> > @@ -2440,7 +2479,24 @@ static int post_relocation(struct module *mod, const
> > struct load_info *info)
> > add_kallsyms(mod, info);
> >
> > /* Arch-specific
On Thu Apr 18, 2024 at 12:01 PM CEST, Konrad Dybcio wrote:
> On 18.04.2024 8:36 AM, Luca Weiss wrote:
> > Add a node for the vibrator module found inside the PMI632.
> >
> > Signed-off-by: Luca Weiss
> > ---
>
> Reviewed-by: Konrad Dybcio
>
> On a side note, this is a totally configuration-free
On 18.04.2024 8:44 AM, Dmitry Baryshkov wrote:
> From: Srinivas Kandagatla
>
> The ADSP provides fastrpc/compute capabilities. Enable support for the
> fastrpc on this DSP.
>
> Signed-off-by: Srinivas Kandagatla
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 18.04.2024 8:36 AM, Luca Weiss wrote:
> Add a node for the vibrator module found inside the PMI632.
>
> Signed-off-by: Luca Weiss
> ---
Reviewed-by: Konrad Dybcio
On a side note, this is a totally configuration-free peripheral that doesn't do
anything crazy until manually configured.
In
On Thu, Apr 18, 2024 at 03:14:37PM +0800, Zhu, Lingshan wrote:
>
>
> On 4/17/2024 4:54 PM, David Stevens wrote:
> > Add support for the VIRTIO_F_SUSPEND feature. When this feature is
> > negotiated, power management can use it to suspend virtio devices
> > instead of resorting to resetting the
On 4/17/2024 4:54 PM, David Stevens wrote:
Add support for the VIRTIO_F_SUSPEND feature. When this feature is
negotiated, power management can use it to suspend virtio devices
instead of resorting to resetting the devices entirely.
Signed-off-by: David Stevens
---
drivers/virtio/virtio.c
On 17.04.24 15:38, Greg KH wrote:
> On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
>> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
>>> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
Could you please create the email alias
On Sat, Apr 06, 2024 at 06:36:46PM +0100, Vincent Donnefort wrote:
> In preparation for allowing the user-space to map a ring-buffer, add
> a set of mapping functions:
>
> ring_buffer_{map,unmap}()
>
> And controls on the ring-buffer:
>
> ring_buffer_map_get_reader() /* swap reader and
MSM8996 provides limited glink support, so add corresponding device tree
nodes. For example the following interfaces are provided on db820c:
modem:
208.remoteproc:glink-edge.LOOPBACK_CTL_MPSS.-1.-1
208.remoteproc:glink-edge.glink_ssr.-1.-1
208.remoteproc:glink-edge.rpmsg_chrdev.0.0
From: Srinivas Kandagatla
The ADSP provides fastrpc/compute capabilities. Enable support for the
fastrpc on this DSP.
Signed-off-by: Srinivas Kandagatla
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 57 +++
1 file changed, 57
Enable the FastRPC and glink-edge nodes on MSM8996 platform. Tested on
APQ8096 Dragonboard820c.
Signed-off-by: Dmitry Baryshkov
---
Changes in v2:
- Fixed order of compute nodes (Konrad)
- Link to v1:
https://lore.kernel.org/r/20240401-msm8996-remoteproc-v1-0-f02ab47fc...@linaro.org
---
Dmitry
MSM8996 has limited glink support, allow glink-edge node on MSM8996
platform.
Acked-by: Rob Herring
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git
Enable the vibrator on the PMI632 which is used on this phone.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
Add a node for the vibrator module found inside the PMI632.
Signed-off-by: Luca Weiss
---
arch/arm64/boot/dts/qcom/pmi632.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/pmi632.dtsi
b/arch/arm64/boot/dts/qcom/pmi632.dtsi
index 94d53b1cf6c8..b4313728f3e7
-fairphone-fp3.dts | 4
2 files changed, 10 insertions(+)
---
base-commit: eecc5d90861b551d3b8fbd0d0e6f25c40496f3c0
change-id: 20240418-fp3-vibra-18c400889853
Best regards,
--
Luca Weiss
Expose memory scan/reclaim information to the host side via virtio
balloon device.
Now we have a metric to analyze the memory performance:
y: counter increases
n: counter does not changes
h: the rate of counter change is high
l: the rate of counter change is low
OOM: VIRTIO_BALLOON_S_OOM_KILL
Memory allocation stall counter represents the performance/latency of
memory allocation, expose this counter to the host side by virtio
balloon device via out-of-bound way.
Signed-off-by: zhenwei pi
---
drivers/virtio/virtio_balloon.c | 20 +++-
When the guest OS runs under critical memory pressure, the guest
starts to kill processes. A guest monitor agent may scan 'oom_kill'
from /proc/vmstat, and reports the OOM KILL event. However, the agent
may be killed and we will loss this critical event(and the later
events).
For now we can also
RFC -> v1:
- several text changes: oom-kill -> oom-kills, SCAN_ASYNC -> ASYN_SCAN.
- move vm events codes into '#ifdef CONFIG_VM_EVENT_COUNTERS'
RFC version:
Link:
https://lore.kernel.org/lkml/20240415084113.1203428-1-pizhen...@bytedance.com/T/#m1898963b3c27a989b1123db475135c3ca687ca84
zhenwei
82 matches
Mail list logo
