Similarly to x86, add MAXSMP that should help flush out problems with
vary large SMP and other values associated with very big systems.
Signed-off-by: Nicholas Piggin
---
Since v1:
- Reduce MAXSMP NR_CPUS to 8192 if COMPILE_TEST, to reduce compile errors
that aren't caught by existing x86 build
In case the FORM2 distance table from firmware is not the expected size,
there is fallback code that just populates the lookup table as local vs
remote.
However it then continues on to use the distance table. Fix.
Reviewed-by: Aneesh Kumar K.V
Fixes: 1c6b5a7e7405 ("powerpc/pseries: Add support f
The name of the local variable holding the "form2" property address
conflicts with the numa_distance_table global.
This patch does 's/numa_dist_table/form2_distances/g' over the function,
which also renames numa_dist_table_length to form2_distances_length.
Suggested-by: Michael Ellerman
Signed-o
Allow the LPID bit width and partition table size to be set at runtime
from the device tree.
Move the PID bit width detection into the same place.
KVM does not support using the extra bits yet, this is mainly required
to get the PTCR register values correct.
Signed-off-by: Nicholas Piggin
---
On a 16-socket 192-core POWER8 system, a context switching benchmark
with as many software threads as CPUs (so each switch will go in and
out of idle), upstream can achieve a rate of about 1 million context
switches per second, due to contention on the mm refcount.
powerpc/64s meets the prerequisi
On big systems, the mm refcount can become highly contented when doing
a lot of context switching with threaded applications (particularly
switching between the idle thread and an application thread).
Abandoning lazy tlb slows switching down quite a bit in the important
user->idle->user cases, so
Add CONFIG_MMU_TLB_REFCOUNT which enables refcounting of the lazy tlb mm
when it is context switched. This can be disabled by architectures that
don't require this refcounting if they clean up lazy tlb mms when the
last refcount is dropped. Currently this is always enabled, which is
what existing c
Add explicit _lazy_tlb annotated functions for lazy mm refcounting.
This makes lazy mm references more obvious, and allows explicit
refcounting to be removed if it is not used.
The non-trivial change in kthread_use_mm/kthread_unuse_mm is because it
is clever with refcounting: If it happens that th
Since v4, this fixes a kthread_use_mm refcounting bug and adds some
comments in code and changelogs around the kthread_use_mm change in
patch 1 (due to akpm's comment -- thanks).
It also adds and improves comments in code, changelogs, and Kconfig
options. The overall design is unchanged though. Pl
Nicholas Piggin writes:
> Slab is up at this point, using the bootmem allocator triggers a
> warning. Switch to using the regular cpumask allocator.
>
> Signed-off-by: Nicholas Piggin
Reviewed-by: Nathan Lynch
> ---
>
> This only matters when CONFIG_CPUMASK_OFFNODE=y, which has not been
> poss
kindly ping...
在 2021/11/3 9:48, He Ying 写道:
Early exits from for_each_compatible_node() should decrease the
node reference count.
Signed-off-by: He Ying
---
arch/powerpc/platforms/embedded6xx/hlwd-pic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/embedded6xx/
Waiman Long writes:
> On 11/8/21 20:46, Nicholas Piggin wrote:
>> Differences between the two patches are error checking - no big deal but
>> we should just do it. And GFP_NOWAIT - is this required here?
>
> As I have replied in another thread, I added it because it was used in
> memblock_alloc_i
On 11/8/21 20:46, Nicholas Piggin wrote:
Excerpts from Michael Ellerman's message of November 9, 2021 11:04 am:
Waiman Long writes:
It was found that the following warning message could be printed out when
booting the kernel on PowerPC systems that support LPAR:
[0.129584] WARNING: CPU:
On 11/8/21 18:06, Nathan Lynch wrote:
Waiman Long writes:
It was found that the following warning message could be printed out when
booting the kernel on PowerPC systems that support LPAR:
[0.129584] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1451
memblock_alloc_internal+0x5c/0x104
[0
Excerpts from Michael Ellerman's message of November 9, 2021 11:04 am:
> Waiman Long writes:
>> It was found that the following warning message could be printed out when
>> booting the kernel on PowerPC systems that support LPAR:
>>
>> [0.129584] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1451
>
On 11/8/21 20:04, Michael Ellerman wrote:
Waiman Long writes:
It was found that the following warning message could be printed out when
booting the kernel on PowerPC systems that support LPAR:
[0.129584] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1451
memblock_alloc_internal+0x5c/0x104
[
Nicholas Piggin writes:
> Excerpts from Michael Ellerman's message of November 8, 2021 3:20 pm:
>> Nicholas Piggin writes:
>>> In case the FORM2 distance table from firmware is not the expected size,
>>> there is fallback code that just populates the lookup table as local vs
>>> remote.
>>>
>>> H
Nicholas Piggin writes:
> Excerpts from Michael Ellerman's message of November 8, 2021 3:28 pm:
>> Nicholas Piggin writes:
>>> Similarly to x86, add MAXSMP that should help flush out problems with
>>> vary large SMP and other values associated with very big systems.
>>>
>>> Signed-off-by: Nichola
Waiman Long writes:
> It was found that the following warning message could be printed out when
> booting the kernel on PowerPC systems that support LPAR:
>
> [0.129584] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1451
> memblock_alloc_internal+0x5c/0x104
> [0.129593] Modules linked in:
> [
Waiman Long writes:
> It was found that the following warning message could be printed out when
> booting the kernel on PowerPC systems that support LPAR:
>
> [0.129584] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1451
> memblock_alloc_internal+0x5c/0x104
> [0.129593] Modules linked in:
> [
On Mon, Nov 08, 2021 at 03:59:26PM -0500, Alan Stern wrote:
> Is there really any reason for returning an error code? For example, is
> it anticipated that at some point in the future these registration calls
> might fail?
>
> Currently, the only reason for failing...
Right, I believe with not
On Mon, Nov 08, 2021 at 05:21:45PM +0100, Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote:
> > Returning void is the other extreme ;-)
> >
> > There are 3 levels (ignoring BUG_ON()/panic () inside the callee):
> > 1. Return void: no one can check succe
On Fri, 5 Nov 2021 19:20:59 +
Marc Zyngier wrote:
> As we are about to change the way vcpus are allocated, mandate
> the use of kvm_get_vcpu() instead of open-coding the access.
>
> Signed-off-by: Marc Zyngier
makes sense
Reviewed-by: Claudio Imbrenda
> ---
> arch/s390/kvm/kvm-s390.c
On Fri, 5 Nov 2021 19:20:57 +
Marc Zyngier wrote:
> All architectures have similar loops iterating over the vcpus,
> freeing one vcpu at a time, and eventually wiping the reference
> off the vcpus array. They are also inconsistently taking
> the kvm->lock mutex when wiping the references fro
08.11.2021 14:22, Jonathan Neuschäfer пишет:
> On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
> [...]
>> EC drivers tend to use higher priority in general. Jonathan, could you
>> please confirm that NTXEC driver is a more preferable restart method
>> than the watchdog?
>
> Yes. T
On Sun, Nov 07, 2021 at 08:42:33PM +0300, Dmitry Osipenko wrote:
[...]
> EC drivers tend to use higher priority in general. Jonathan, could you
> please confirm that NTXEC driver is a more preferable restart method
> than the watchdog?
Yes. The original firmware uses the NTXEC to restart, and it w
It was found that the following warning message could be printed out when
booting the kernel on PowerPC systems that support LPAR:
[0.129584] WARNING: CPU: 0 PID: 1 at mm/memblock.c:1451
memblock_alloc_internal+0x5c/0x104
[0.129593] Modules linked in:
[0.129598] CPU: 0 PID: 1 Comm: sw
On Mon, Nov 08, 2021 at 11:23:13AM -0500, Steven Rostedt wrote:
> Question, how often does this warning trigger? Is it common to see in
> development?
Yeah, haven't seen it myself yet.
But we hashed it out over IRC. :-)
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-ne
On Mon, 8 Nov 2021 15:35:50 +0100
Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> > I guess I can add another indirection to notifier_chain_register() and
> > avoid touching all the call sites.
>
> IOW, something like this below.
>
> This way I won'
On Mon, Nov 08, 2021 at 05:12:16PM +0100, Geert Uytterhoeven wrote:
> Returning void is the other extreme ;-)
>
> There are 3 levels (ignoring BUG_ON()/panic () inside the callee):
> 1. Return void: no one can check success or failure,
> 2. Return an error code: up to the caller to decide,
>
Hi Borislav,
On Mon, Nov 8, 2021 at 4:59 PM Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> > I'm not against returning proper errors codes. I'm against forcing
> > callers to check things that cannot fail and to add individual error
> > printing to
On Mon, Nov 08, 2021 at 04:25:47PM +0100, Geert Uytterhoeven wrote:
> I'm not against returning proper errors codes. I'm against forcing
> callers to check things that cannot fail and to add individual error
> printing to each and every caller.
If you're against checking things at the callers, th
Hi Borislav,
On Mon, Nov 8, 2021 at 3:21 PM Borislav Petkov wrote:
> On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> > I think the addition of __must_check is overkill, leading to the
> > addition of useless error checks and message printing.
>
> See the WARN in notifier_cha
Hi Cai,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.15 next-20211108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documente
On Mon, Nov 08, 2021 at 11:30:10AM +0530, Kajol Jain wrote:
> Add pmu metric json file for power10 platform.
>
> Signed-off-by: Kajol Jain
> ---
> Changelog
> v2 -> v3:
> - Did nit changes in BriefDescription as suggested
> by Paul A. Clarke and Michael Ellermen
LGTM.
Reviewed-by: Paul A. Cla
On Mon, Nov 08, 2021 at 03:24:39PM +0100, Borislav Petkov wrote:
> I guess I can add another indirection to notifier_chain_register() and
> avoid touching all the call sites.
IOW, something like this below.
This way I won't have to touch all the callsites and the registration
routines would still
On Mon, Nov 08, 2021 at 09:17:03AM -0500, Alan Stern wrote:
> What reason is there for moving the check into the callers? It seems
> like pointless churn. Why not add the error return code, change the
> WARN to pr_warn, and leave the callers as they are? Wouldn't that end
> up having exactly
On Mon, Nov 08, 2021 at 11:19:24AM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Hi all,
>
> this is a huge patchset for something which is really trivial - it
> changes the notifier registration routines to return an error value
> if a notifier callback is already present on the res
On Mon, Nov 08, 2021 at 03:07:03PM +0100, Geert Uytterhoeven wrote:
> I think the addition of __must_check is overkill, leading to the
> addition of useless error checks and message printing.
See the WARN in notifier_chain_register() - it will already do "message
printing".
> Many callers call th
Excerpts from Ganesh Goudar's message of November 8, 2021 6:38 pm:
> In realmode mce handler we use irq_work_queue() to defer
> the processing of mce events, irq_work_queue() can only
> be called when translation is enabled because it touches
> memory outside RMA, hence we enable translation before
Hi Borislav,
On Mon, Nov 8, 2021 at 11:13 AM Borislav Petkov wrote:
> From: Borislav Petkov
>
> The notifier registration routine doesn't return a proper error value
> when a callback has already been registered, leading people to track
> whether that registration has happened at the call site:
Excerpts from Michael Ellerman's message of November 8, 2021 3:28 pm:
> Nicholas Piggin writes:
>> Similarly to x86, add MAXSMP that should help flush out problems with
>> vary large SMP and other values associated with very big systems.
>>
>> Signed-off-by: Nicholas Piggin
>> ---
>> arch/powerp
Excerpts from Michael Ellerman's message of November 8, 2021 3:20 pm:
> Nicholas Piggin writes:
>> In case the FORM2 distance table from firmware is not the expected size,
>> there is fallback code that just populates the lookup table as local vs
>> remote.
>>
>> However it then continues on to us
Hello,
On Mon, Nov 08, 2021 at 09:18:56AM +1100, Daniel Axtens wrote:
> Michal Suchánek writes:
>
> > On Fri, Nov 05, 2021 at 09:55:52PM +1100, Daniel Axtens wrote:
> >> Michal Suchanek writes:
> >>
> >> > S390 uses appended signature for kernel but implements the check
> >> > separately from
Dmitry Osipenko writes:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
>
> Signed-off-by: Dm
From: Borislav Petkov
The notifier registration routine doesn't return a proper error value
when a callback has already been registered, leading people to track
whether that registration has happened at the call site:
https://lore.kernel.org/amd-gfx/20210512013058.6827-1-mukul.jo...@amd.com/
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Signed-off-by: Borislav Petkov
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/setup-common.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kern
From: Borislav Petkov
Avoid homegrown notifier registration checks.
No functional changes.
Reported-by: kernel test robot
Signed-off-by: Borislav Petkov
Cc: linuxppc-dev@lists.ozlabs.org
---
drivers/macintosh/adbhid.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/dr
From: Borislav Petkov
Hi all,
this is a huge patchset for something which is really trivial - it
changes the notifier registration routines to return an error value
if a notifier callback is already present on the respective list of
callbacks. For more details scroll to the last patch.
Everythi
On 9/6/21 14:13, Ganesh Goudar wrote:
Add support to parse and log control memory access
error for pseries. These changes are made according to
PAPR v2.11 10.3.2.2.12.
Signed-off-by: Ganesh Goudar
---
v3: Modify the commit log to mention the document according
to which changes are made.
Now that we are no longer switching on the mmu in realmode
mce handler, Revert the commit 4ff753feab02("powerpc/pseries:
Avoid using addr_to_pfn in real mode") partially, which
introduced functions mce_handle_err_virtmode/realmode() to
separate mce handler code which needed translation to enabled.
In realmode mce handler we use irq_work_queue() to defer
the processing of mce events, irq_work_queue() can only
be called when translation is enabled because it touches
memory outside RMA, hence we enable translation before
calling irq_work_queue and disable on return, though it
is not safe to do
On 2021-11-06 11:48, Marc Zyngier wrote:
On Fri, 05 Nov 2021 20:21:36 +,
Sean Christopherson wrote:
On Fri, Nov 05, 2021, Marc Zyngier wrote:
> At least on arm64 and x86, the vcpus array is pretty huge (512 entries),
> and is mostly empty in most cases (running 512 vcpu VMs is not that
> c
53 matches
Mail list logo
