On Mon, Jan 29, 2024 at 02:17:29PM +0100, Lukas Bulwahn wrote:
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2fb944964be5..15bc79e80e28 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10307,12 +10307,12 @@ M: Nayna Jain
> M: Paulo Flabiano Smorigo
> L: linux-cry...@vger.kernel.or
On Wed, Jan 31, 2024 at 06:53:13AM +, Christophe Leroy wrote:
> The problem being identified in commit 677bfb9db8a3 ("module: Don't
> ignore errors from set_memory_XX()"), you can keep/re-apply the series
> [PATCH 1/3] init: Declare rodata_enabled and mark_rodata_ro() at all time.
Sure, queu
Hi Christophe,
On 31.01.2024 21:07, Christophe Leroy wrote:
> Le 31/01/2024 à 16:17, Marek Szyprowski a écrit :
>> [Vous ne recevez pas souvent de courriers de m.szyprow...@samsung.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> On 31.01.2
Le 31/01/2024 à 16:17, Marek Szyprowski a écrit :
> [Vous ne recevez pas souvent de courriers de m.szyprow...@samsung.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Christophe,
>
> On 31.01.2024 12:58, Christophe Leroy wrote:
>> Le 30/0
The preventive sfence.vma were emitted because new mappings must be made
visible to the page table walker but Svvptc guarantees that xRET act as
a fence, so no need to sfence.vma for the uarchs that implement this
extension.
This allows to drastically reduce the number of sfence.vma emitted:
* Ub
In 6.5, we removed the vmalloc fault path because that can't work (see
[1] [2]). Then in order to make sure that new page table entries were
seen by the page table walker, we had to preventively emit a sfence.vma
on all harts [3] but this solution is very costly since it relies on IPI.
And even th
Add description for the Svvptc ISA extension which was ratified recently.
Signed-off-by: Alexandre Ghiti
---
Documentation/devicetree/bindings/riscv/extensions.yaml | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml
b/Documentation
Add support to parse the Svvptc string in the riscv,isa string.
Signed-off-by: Alexandre Ghiti
---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/kernel/cpufeature.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 5340
In RISC-V, after a new mapping is established, a sfence.vma needs to be
emitted for different reasons:
- if the uarch caches invalid entries, we need to invalidate it otherwise
we would trap on this invalid entry,
- if the uarch does not cache invalid entries, a reordered access could fail
to
Hi Christophe,
On 31.01.2024 12:58, Christophe Leroy wrote:
> Le 30/01/2024 à 18:48, Marek Szyprowski a écrit :
>> [Vous ne recevez pas souvent de courriers de m.szyprow...@samsung.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> On 30.01.2
dontneed should hopefully/likely see a speedup.
Yes, but that's almost exactly the same path as munmap, so I'm sure it really
adds much for this particular series.
Right, that's why I'm not including these measurements. dontneed vs.
munmap is more about measuring the overhead of VMA modifica
On 31/01/2024 15:05, David Hildenbrand wrote:
> On 31.01.24 16:02, Ryan Roberts wrote:
>> On 31/01/2024 14:29, David Hildenbrand wrote:
> Note that regarding NUMA effects, I mean when some memory access within
> the
> same
> socket is faster/slower even with only a single node. On
On 31.01.24 16:02, Ryan Roberts wrote:
On 31/01/2024 14:29, David Hildenbrand wrote:
Note that regarding NUMA effects, I mean when some memory access within the same
socket is faster/slower even with only a single node. On AMD EPYC that's
possible, depending on which core you are running and on
On 31/01/2024 14:29, David Hildenbrand wrote:
>>> Note that regarding NUMA effects, I mean when some memory access within the
>>> same
>>> socket is faster/slower even with only a single node. On AMD EPYC that's
>>> possible, depending on which core you are running and on which memory
>>> control
Note that regarding NUMA effects, I mean when some memory access within the same
socket is faster/slower even with only a single node. On AMD EPYC that's
possible, depending on which core you are running and on which memory controller
the memory you want to access is located. If both are in differ
On 31.01.24 15:08, Michal Hocko wrote:
On Wed 31-01-24 10:26:13, Ryan Roberts wrote:
IIRC there is an option to zero memory when it is freed back to the buddy? So
that could be a place where time is proportional to size rather than
proportional to folio count? But I think that option is intended
On Wed 31-01-24 11:16:01, David Hildenbrand wrote:
[...]
> This 1 pages limit was introduced in 53a59fc67f97 ("mm: limit mmu_gather
> batching to fix soft lockups on !CONFIG_PREEMPT") where we wanted to handle
> soft-lockups.
AFAIR at the time of this patch this was mostly just to put some cap
On Wed 31-01-24 10:26:13, Ryan Roberts wrote:
> IIRC there is an option to zero memory when it is freed back to the buddy? So
> that could be a place where time is proportional to size rather than
> proportional to folio count? But I think that option is intended for debug
> only?
> So perhaps not
On 31/01/2024 13:38, David Hildenbrand wrote:
Nope: looks the same. I've taken my test harness out of the picture and
done
everything manually from the ground up, with the old tests and the new.
Headline
is that I see similar numbers from both.
>>>
>>> I took me a while to
Nope: looks the same. I've taken my test harness out of the picture and done
everything manually from the ground up, with the old tests and the new. Headline
is that I see similar numbers from both.
I took me a while to get really reproducible numbers on Intel. Most importantly:
* Set a fixed CP
On 31/01/2024 12:56, David Hildenbrand wrote:
> On 31.01.24 13:37, Ryan Roberts wrote:
>> On 31/01/2024 11:49, Ryan Roberts wrote:
>>> On 31/01/2024 11:28, David Hildenbrand wrote:
On 31.01.24 12:16, Ryan Roberts wrote:
> On 31/01/2024 11:06, David Hildenbrand wrote:
>> On 31.01.24 11:
Calling get_system_loc_code before checking devfd and errno - fails the test
when the device is not available, expected a SKIP.
Change the order of 'SKIP_IF_MSG' correctly SKIP when the /dev/papr-vpd device
is not available.
with out patch: Test FAILED on line 271
with patch: [SKIP] Test skipped o
I'm also surprised about the dontneed vs. munmap numbers.
You mean the ones for Altra that I posted? (I didn't post any for M2). The altra
numbers look ok to me; dontneed has no change, and munmap has no change for
order-0 and is massively improved for order-9.
I would expect that dontneed w
On 31.01.24 13:37, Ryan Roberts wrote:
On 31/01/2024 11:49, Ryan Roberts wrote:
On 31/01/2024 11:28, David Hildenbrand wrote:
On 31.01.24 12:16, Ryan Roberts wrote:
On 31/01/2024 11:06, David Hildenbrand wrote:
On 31.01.24 11:43, Ryan Roberts wrote:
On 29/01/2024 12:46, David Hildenbrand wro
On 31/01/2024 11:49, Ryan Roberts wrote:
> On 31/01/2024 11:28, David Hildenbrand wrote:
>> On 31.01.24 12:16, Ryan Roberts wrote:
>>> On 31/01/2024 11:06, David Hildenbrand wrote:
On 31.01.24 11:43, Ryan Roberts wrote:
> On 29/01/2024 12:46, David Hildenbrand wrote:
>> Now that the rm
Hi,
Le 30/01/2024 à 18:48, Marek Szyprowski a écrit :
> [Vous ne recevez pas souvent de courriers de m.szyprow...@samsung.com.
> Découvrez pourquoi ceci est important à
> https://aka.ms/LearnAboutSenderIdentification ]
>
> Dear All,
>
> On 30.01.2024 12:03, Christophe Leroy wrote:
>> Le 30/01/
On 31/01/2024 11:28, David Hildenbrand wrote:
> On 31.01.24 12:16, Ryan Roberts wrote:
>> On 31/01/2024 11:06, David Hildenbrand wrote:
>>> On 31.01.24 11:43, Ryan Roberts wrote:
On 29/01/2024 12:46, David Hildenbrand wrote:
> Now that the rmap overhaul[1] is upstream that provides a clean
Hi,
Got the following BUG while loading module test_bpf.ko
No time to investigate for now.
root@vgoip:~# insmod test_bpf.ko
[ 263.409030]
==
[ 263.416415] BUG: KASAN: vmalloc-out-of-bounds in memset32+0x5c/0xa0
[ 263.422952] Wri
Patch looks fine to me.
Reviewed-by: Kajol Jain
Thanks,
Kajol Jain
On 1/29/24 17:38, Madhavan Srinivasan wrote:
> Update the Power11 PVR to json mapfile to enable
> json events. Power11 is PowerISA v3.1 compliant
> and support Power10 events.
>
> Signed-off-by: Madhavan Srinivasan
> ---
> to
Running event
hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles,phys_processor_idx=0/
in one of the system throws below error:
---Logs---
# perf list | grep
hv_gpci/dispatch_timebase_by_processor_processor_time_in_timebase_cycles
hv_gpci/dispatch_timebase_by_processor
On 31.01.24 12:16, Ryan Roberts wrote:
On 31/01/2024 11:06, David Hildenbrand wrote:
On 31.01.24 11:43, Ryan Roberts wrote:
On 29/01/2024 12:46, David Hildenbrand wrote:
Now that the rmap overhaul[1] is upstream that provides a clean interface
for rmap batching, let's implement PTE batching du
On 31/01/2024 11:06, David Hildenbrand wrote:
> On 31.01.24 11:43, Ryan Roberts wrote:
>> On 29/01/2024 12:46, David Hildenbrand wrote:
>>> Now that the rmap overhaul[1] is upstream that provides a clean interface
>>> for rmap batching, let's implement PTE batching during fork when processing
>>> P
- folio_remove_rmap_pte(folio, page, vma);
+ folio_remove_rmap_ptes(folio, page, nr, vma);
+
+ /* Only sanity-check the first page in a batch. */
if (unlikely(page_mapcount(page) < 0))
print_bad_pte(vma, addr, ptent, page);
Is there a case for eithe
On 31.01.24 11:43, Ryan Roberts wrote:
On 29/01/2024 12:46, David Hildenbrand wrote:
Now that the rmap overhaul[1] is upstream that provides a clean interface
for rmap batching, let's implement PTE batching during fork when processing
PTE-mapped THPs.
This series is partially based on Ryan's pr
On 2024-01-31 9:19 am, Tasmiya Nalatwad wrote:
Greetings,
[mainline] [linux-next] [6.8-rc1] [DLPAR] OOps kernel crash after
performing dlpar remove test
--- Traces ---
[58563.146236] BUG: Unable to handle kernel data access at
0x6b6b6b6b6b6b6b83
[58563.146242] Faulting instruction address:
On 29/01/2024 12:46, David Hildenbrand wrote:
> Now that the rmap overhaul[1] is upstream that provides a clean interface
> for rmap batching, let's implement PTE batching during fork when processing
> PTE-mapped THPs.
>
> This series is partially based on Ryan's previous work[2] to implement
> co
On 1/31/2024 6:30 PM, David Hildenbrand wrote:
On 31.01.24 03:30, Yin Fengwei wrote:
On 1/29/24 22:32, David Hildenbrand wrote:
+static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm,
+ unsigned long addr, pte_t *ptep, unsigned int nr, int full)
+{
+ pte_t pte, tmp_pte
On 31.01.24 03:20, Yin Fengwei wrote:
On 1/29/24 22:32, David Hildenbrand wrote:
This series is based on [1] and must be applied on top of it.
Similar to what we did with fork(), let's implement PTE batching
during unmap/zap when processing PTE-mapped THPs.
We collect consecutive PTEs that map
On 31/01/2024 10:21, David Hildenbrand wrote:
>
>>> +
>>> +#ifndef clear_full_ptes
>>> +/**
>>> + * clear_full_ptes - Clear PTEs that map consecutive pages of the same
>>> folio.
>>
>> I know its implied from "pages of the same folio" (and even more so for the
>> above variant due to mention of a
On 31.01.24 03:30, Yin Fengwei wrote:
On 1/29/24 22:32, David Hildenbrand wrote:
+static inline pte_t get_and_clear_full_ptes(struct mm_struct *mm,
+ unsigned long addr, pte_t *ptep, unsigned int nr, int full)
+{
+ pte_t pte, tmp_pte;
+
+ pte = ptep_get_and_clear_full
On 31/01/2024 10:16, David Hildenbrand wrote:
> On 31.01.24 03:20, Yin Fengwei wrote:
>> On 1/29/24 22:32, David Hildenbrand wrote:
>>> This series is based on [1] and must be applied on top of it.
>>> Similar to what we did with fork(), let's implement PTE batching
>>> during unmap/zap when proces
+
+#ifndef clear_full_ptes
+/**
+ * clear_full_ptes - Clear PTEs that map consecutive pages of the same folio.
I know its implied from "pages of the same folio" (and even more so for the
above variant due to mention of access/dirty), but I wonder if its useful to
explicitly state that "all pt
On 31.01.24 03:20, Yin Fengwei wrote:
On 1/29/24 22:32, David Hildenbrand wrote:
This series is based on [1] and must be applied on top of it.
Similar to what we did with fork(), let's implement PTE batching
during unmap/zap when processing PTE-mapped THPs.
We collect consecutive PTEs that map
Greetings,
[mainline] [linux-next] [6.8-rc1] [DLPAR] OOps kernel crash after
performing dlpar remove test
--- Traces ---
[58563.146236] BUG: Unable to handle kernel data access at
0x6b6b6b6b6b6b6b83
[58563.146242] Faulting instruction address: 0xc09c0e60
[58563.146248] Oops: Kernel
On Tue, Jan 30, 2024 at 06:26:39PM -0800, Kuppuswamy Sathyanarayanan wrote:
>
> On 1/24/24 10:27 PM, Wang, Qingshun wrote:
> > When Advisory Non-Fatal errors are raised, both correctable and
>
> Maybe you can start with same info about what Advisory Non-FataL
> errors are and the specification re
45 matches
Mail list logo
