[PATCH v5 04/15] sparc: simplify module_alloc()

From: "Mike Rapoport (IBM)" Define MODULES_VADDR and MODULES_END as VMALLOC_START and VMALLOC_END for 32-bit and reduce module_alloc() to __vmalloc_node_range(size, 1, MODULES_VADDR, MODULES_END, ...) as with the new defines the allocations becames identical for both 32 and 64 bits.

[PATCH v5 03/15] nios2: define virtual address space for modules

From: "Mike Rapoport (IBM)" nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26 cannot reach all of vmalloc address space. Define module space as 32MiB below the kernel base and switch nios2 to use vmalloc for module allocations. Suggested-by: Thomas Gleixner Acked-by:

[PATCH v5 02/15] mips: module: rename MODULE_START to MODULES_VADDR

From: "Mike Rapoport (IBM)" and MODULE_END to MODULES_END to match other architectures that define custom address space for modules. Signed-off-by: Mike Rapoport (IBM) --- arch/mips/include/asm/pgtable-64.h | 4 ++-- arch/mips/kernel/module.c | 4 ++-- arch/mips/mm/fault.c

[PATCH v5 01/15] arm64: module: remove unneeded call to kasan_alloc_module_shadow()

From: "Mike Rapoport (IBM)" Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS modes") KASAN_VMALLOC is always enabled when KASAN is on. This means that allocations in module_alloc() will be tracked by KASAN protection for vmalloc() and that kasan_alloc_module_shadow() will

Re: [PATCH net-next v7 1/7] net: introduce rstreason to detect why the RST is sent

Hi Jason, On 22/04/2024 05:01, Jason Xing wrote: > 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. Thank you for looking at that! (...) > diff --git a/include/net/rstreason.h

Re: [PATCH v2] ipvs: Fix checksumming on GSO of SCTP packets

Hello, On Sun, 21 Apr 2024, Ismael Luceno wrote: > 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. >

[PATCH v5 00/15] mm: jit/text allocator

From: "Mike Rapoport (IBM)" Hi, Since v3 I looked into making execmem more of an utility toolbox, as we discussed at LPC with Mark Rutland, but it was getting more hairier than having a struct describing architecture constraints and a type identifying the consumer of execmem. And I do think

Re: Re: [PATCH v2 1/4] virtio_balloon: separate vm events into a function

On 4/22/24 15:47, David Hildenbrand wrote: On 22.04.24 09:42, zhenwei pi wrote: All the VM events related statistics have dependence on 'CONFIG_VM_EVENT_COUNTERS', once any stack variable is required by any VM events in future, we would have codes like:   #ifdef CONFIG_VM_EVENT_COUNTERS  

Re: [PATCH v2 3/4] virtio_balloon: introduce memory allocation stall counter

On 22.04.24 09:42, 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 | 8

Re: [PATCH v2 1/4] virtio_balloon: separate vm events into a function

On 22.04.24 09:42, zhenwei pi wrote: All the VM events related statistics have dependence on 'CONFIG_VM_EVENT_COUNTERS', once any stack variable is required by any VM events in future, we would have codes like: #ifdef CONFIG_VM_EVENT_COUNTERS unsigned long foo; #endif ...

[PATCH v2 4/4] virtio_balloon: introduce memory scan/reclaim info

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

[PATCH v2 3/4] virtio_balloon: introduce memory allocation stall counter

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 | 8 include/uapi/linux/virtio_balloon.h | 6

[PATCH v2 2/4] virtio_balloon: introduce oom-kill invocations

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

[PATCH v2 1/4] virtio_balloon: separate vm events into a function

All the VM events related statistics have dependence on 'CONFIG_VM_EVENT_COUNTERS', once any stack variable is required by any VM events in future, we would have codes like: #ifdef CONFIG_VM_EVENT_COUNTERS unsigned long foo; #endif ... #ifdef CONFIG_VM_EVENT_COUNTERS foo =

[PATCH v2 0/4] Improve memory statistics for virtio balloon

Hi, v1 -> v2: - Add a new patch 'virtio_balloon: separate vm events into a function' to avoid any compiler warnings(unused stack variable on CONFIG_VM_EVENT_COUNTERS=n) - Suggested by David, use a loop 'for (zid = 0; zid < MAX_NR_ZONES; zid++)' to obtain all the stall events. RFC -> v1: -

Re: [PATCH net-next v3 1/2] ipvs: add READ_ONCE barrier for ipvs->sysctl_amemthresh

On Sun, Apr 21, 2024 at 1:06 PM Julian Anastasov wrote: > > > Hello, Dear Julian, Thanks a lot for the fast review and suggestions! Kind regards, Alex > > On Thu, 18 Apr 2024, Alexander Mikhalitsyn wrote: > > > Cc: Julian Anastasov > > Cc: Simon Horman > > Cc: Pablo Neira Ayuso > >

[PATCH v2 1/1] virtio: Add support for the virtio suspend feature

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| 60 ++

[PATCH v2 0/1] virtio: Add suspend support

This series implements support for the virtio device suspend feature that is under discussion. Unfortunately, the virtio mailing list is currently being migrated, so recent discussion of the proposal is not archived anywhere. There current version of the proposal is a combination of [1] and [2].

<    1   2