Changelog v4->v5:
v4:
http://lore.kernel.org/lkml/20200727053230.19753-1-sri...@linux.vnet.ibm.com/t/#u
Changelog v4 ->v5:
powerpc/smp: Optimize start_secondary
Retain cache domain, no need for generalization
(Michael Ellerman, Peter Zijlstra,
Valentin Sc
Just moving the powerpc_topology description above.
This will help in using functions in this file and avoid declarations.
No other functional changes
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Anton Blanchard
Cc: Oliver O'Halloran
Cc: Nathan Lynch
Cc: Michael N
Current code assumes that cpumask of cpus sharing a l2-cache mask will
always be a superset of cpu_sibling_mask.
Lets stop that assumption. cpu_l2_cache_mask is a superset of
cpu_sibling_mask if and only if shared_caches is set.
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Nicholas Piggi
Move topology fixup based on the platform attributes into its own
function which is called just before set_sched_topology.
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Anton Blanchard
Cc: Oliver O'Halloran
Cc: Nathan Lynch
Cc: Michael Neuling
Cc: Gautham R Shenoy
In start_secondary, even if shared_cache was already set, system does a
redundant match for cpumask. This redundant check can be removed by
checking if shared_cache is already set.
While here, localize the sibling_mask variable to within the if
condition.
Cc: linuxppc-dev
Cc: LKML
Cc: Michael E
Add support for grouping cores based on the device-tree classification.
- The last domain in the associativity domains always refers to the
core.
- If primary reference domain happens to be the penultimate domain in
the associativity domains device-tree property, then there are no
coregroups. Howev
Add percpu coregroup maps and masks to create coregroup domain.
If a coregroup doesn't exist, the coregroup domain will be degenerated
in favour of SMT/CACHE domain. Do note this patch is only creating stubs
for cpu_to_coregroup_id. The actual cpu_to_coregroup_id implementation
would be in a subseq
Lookup the coregroup id from the associativity array.
If unable to detect the coregroup id, fallback on the core id.
This way, ensure sched_domain degenerates and an extra sched domain is
not created.
Ideally this function should have been implemented in
arch/powerpc/kernel/smp.c. However if its
If allocated earlier and the search fails, then cpu_l1_cache_map cpumask
is unnecessarily cleared. However cpu_l1_cache_map can be allocated /
cleared after we search thread group.
Please note CONFIG_CPUMASK_OFFSTACK is not set on Powerpc. Hence cpumask
allocated by zalloc_cpumask_var_node is neve
Fix a build warning in a non CONFIG_NEED_MULTIPLE_NODES
"error: _numa_cpu_lookup_table_ undeclared"
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Anton Blanchard
Cc: Oliver O'Halloran
Cc: Nathan Lynch
Cc: Michael Neuling
Cc: Gautham R Shenoy
Cc: Ingo Molnar
Cc: P
A new sched_domain_topology_level was added just for Power9. However the
same can be achieved by merging powerpc_topology with power9_topology
and makes the code more simpler especially when adding a new sched
domain.
Cc: linuxppc-dev
Cc: LKML
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Anton
* Aneesh Kumar K.V [2020-08-06 16:14:21]:
> >
> > associativity_to_nid gets called the first time a cpu is being made present
> > from offline. So it need not be in boot path. We may to verify if cpu
> > hotplug, dlpar, operations are synchronized. For example a memory hotadd and
> > cpu hotplug
Hello Aneesh,
I tested the new kernel today and unfortunately it doesn't run very well.
I have only one core (1 physical processor; 1 core; 2 threads) instead
of two cores (1 physical processor; 2 cores; 2 threads) so the system is
slower.
Boot log: http://www.xenosoft.de/dmesg_nemo_board_ke
Commit ea0eada45632 leads to the following build failure on powerpc:
HOSTCC scripts/recordmcount
scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclared (first use in
this function)
scripts/recordmcount.c:440: error: (Each un
This patch prepares for the incoming patch which swaps the order of
KOBJ_ADD/REMOVE uevent and dt's updating.
The dt updating should come after lmb operations, and before
__remove_memory()/__add_memory(). Accordingly, grouping all lmb operations
before the memblock's.
Signed-off-by: Pingfan Liu
A bug is observed on pseries by taking the following steps on rhel:
-1. drmgr -c mem -r -q 5
-2. echo c > /proc/sysrq-trigger
And then, the failure looks like:
kdump: saving to /sysroot//var/crash/127.0.0.1-2020-01-16-02:06:14/
kdump: saving vmcore-dmesg.txt
kdump: saving vmcore-dmesg.txt complete
On 8/10/20 2:15 PM, Christian Zigotzky wrote:
Hello Aneesh,
I tested the new kernel today and unfortunately it doesn't run very well.
I have only one core (1 physical processor; 1 core; 2 threads) instead
of two cores (1 physical processor; 2 cores; 2 threads) so the system is
slower.
Boot
On Fri, Aug 07, 2020 at 05:27:13PM +0200, Stephen Kitt wrote:
> The i2c probe functions here don't use the id information provided in
> their second argument, so the single-parameter i2c probe function
> ("probe_new") can be used instead.
>
> This avoids scanning the identifier tables during probe
Am 10.08.20 um 10:58 schrieb Aneesh Kumar K.V:
On 8/10/20 2:15 PM, Christian Zigotzky wrote:
Hello Aneesh,
I tested the new kernel today and unfortunately it doesn't run very
well.
I have only one core (1 physical processor; 1 core; 2 threads)
instead of two cores (1 physical processor; 2 c
On p6 and before we should avoid updating UAMOR SPRN. This resulted
in boot failure on Nemo board.
Fixes: 269e829f48a0 ("powerpc/book3s64/pkey: Disable pkey on POWER6 and before")
Reported-by: Christian Zigotzky
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/mm/book3s64/hash_utils.c | 5 ++--
On Mon, Aug 10, 2020 at 11:17:30AM +0200, Gregory Herrero wrote:
> On Mon, Aug 10, 2020 at 08:48:22AM +, Christophe Leroy wrote:
> > Commit ea0eada45632 leads to the following build failure on powerpc:
> >
> > HOSTCC scripts/recordmcount
> > scripts/recordmcount.c: In function 'arm64_is_fak
Hello,
Just for info. The latest git kernel doesn't work with a virtio_gpu anymore.
QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm -m
1024 -kernel uImage -drive
format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic
user,model=e1000 -append "rw root=/dev/vda
Vaibhav Jain writes:
> The newly introduced 'perf_stats' attribute uses the default access
> mode of 0444 letting non-root users access performance stats of an
> nvdimm and potentially force the kernel into issuing large number of
> expensive HCALLs. Since the information exposed by this attribute
On Mon, 10 Aug 2020 13:18:55 +0100
Catalin Marinas wrote:
> > Oops, thanks for fixing this.
> >
> > Acked-by: Gregory Herrero
>
> Thanks. I'll queue it via the arm64 tree (as I did with the previous
> fix) but I'll wait a bit for Steve to ack it.
Acked-by: Steven Rostedt (VMware)
-- Steve
On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote:
>
> With all due respect, but this makes no sense.
I agree. This is a lot of churn for no gain.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.
On Mon, 10 Aug 2020 08:48:22 + (UTC), Christophe Leroy wrote:
> Commit ea0eada45632 leads to the following build failure on powerpc:
>
> HOSTCC scripts/recordmcount
> scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> scripts/recordmcount.c:440: error: 'R_AARCH64_CALL26' undeclar
Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
Implement queued spinlocks and rwlocks").
Signed-off-by: Tobias Klauser
---
Documentation/features/locking/queued-rwlocks/arch-support.txt | 2 +-
.../features/locking/queued-spinlocks/arch-support.txt | 2 +-
2 files ch
Le 10/08/2020 à 12:09, Tobias Klauser a écrit :
Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
Implement queued spinlocks and rwlocks").
Signed-off-by: Tobias Klauser
---
Documentation/features/locking/queued-rwlocks/arch-support.txt | 2 +-
.../features/locking/queued
On 2020-08-10 at 17:09:51 +0200, Christophe Leroy
wrote:
>
>
> Le 10/08/2020 à 12:09, Tobias Klauser a écrit :
> > Support for these was added by commit aa65ff6b18e0 ("powerpc/64s:
> > Implement queued spinlocks and rwlocks").
> >
> > Signed-off-by: Tobias Klauser
> > ---
> > Documentation/
On Mon, Aug 10, 2020 at 05:33:39PM +0300, Horia Geantă wrote:
> On 8/10/2020 4:45 PM, Herbert Xu wrote:
> > On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote:
> >>
> >> With all due respect, but this makes no sense.
> >
> > I agree. This is a lot of churn for no gain.
> >
> I w
Michael Ellerman writes:
> One thought, which I possibly should not put in writing, is that we
> could use the alignment of the pointer as a poor man's substitute for a
> counter, eg:
>
> +static inline struct drmem_lmb *drmem_lmb_next(struct drmem_lmb *lmb)
> +{
> + if (lmb % PAGE_SIZE == 0)
On Mon, Aug 10, 2020 at 04:11:43PM +0800, Shengjiu Wang wrote:
> On some platform(.e.g. i.MX8QM MEK), the "extal" clock is different
> with the mclk of codec, then the clock rate is also different.
> So it is better to get clock rate of "extal" rate by clk_get_rate,
> don't reuse the clock rate of
Hi Christophe,
On Mon, Aug 10, 2020 at 08:48:22AM +, Christophe Leroy wrote:
> Commit ea0eada45632 leads to the following build failure on powerpc:
>
> HOSTCC scripts/recordmcount
> scripts/recordmcount.c: In function 'arm64_is_fake_mcount':
> scripts/recordmcount.c:440: error: 'R_AARCH64_
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Andrei Botila
> Sent: Friday, August 7, 2020 6:20 PM
> To: Herbert Xu ; David S. Miller
>
> Cc: linux-cry...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-ker...@vger.kernel.org; linuxppc-de
On 8/10/2020 4:45 PM, Herbert Xu wrote:
> On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote:
>>
>> With all due respect, but this makes no sense.
>
> I agree. This is a lot of churn for no gain.
>
I would say the gain is that all skcipher algorithms would behave the same
when i
+ David from IBM.
-Original Message-
From: Oliver O'Halloran
Sent: Monday, August 3, 2020 2:35 AM
To: Max Gurtovoy
Cc: Christoph Hellwig ; linux-pci ;
linuxppc-dev ; Israel Rukshin
; Idan Werpoler ; Vladimir Koushnir
; Shlomi Nimrodi ; Frederic
Barrat ; Carol Soto ; Aneela
Devarase
> -Original Message-
> From: Horia Geantă
> Sent: Monday, August 10, 2020 4:34 PM
> To: Herbert Xu ; Van Leeuwen, Pascal
>
> Cc: Andrei Botila (OSS) ; David S. Miller
> ; linux-cry...@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
> linuxppc-dev
At memory hot-remove time we can retrieve an LMB's nid from its
corresponding memory_block. There is no need to store the nid
in multiple locations.
Note that lmb_to_memblock() uses find_memory_block() to get the
corresponding memory_block. As find_memory_block() runs in sub-linear
time this app
https://bugzilla.kernel.org/show_bug.cgi?id=205183
--- Comment #6 from Michael Ellerman (mich...@ellerman.id.au) ---
Fixed in 63dee5df43a3 ("powerpc: Allow 4224 bytes of stack expansion for the
signal frame")
--
You are receiving this mail because:
You are watching the assignee of the bug.
Before entering a guest, we need to set the HDEC to pull us out again
when the guest's time is up. This needs some care, though, because the
HDEC is edge triggered, which means that if it expires before entering the
guest, the interrupt will be lost, meaning we stay in the guest
indefinitely (in p
Quoting Nathan Lynch (2020-08-07 02:05:09)
> Hi everyone,
>
> Michael Ellerman writes:
> > Greg Kurz writes:
> >> On Tue, 04 Aug 2020 23:35:10 +1000
> >> Michael Ellerman wrote:
> >>> Spinning forever seems like a bad idea, but as has been demonstrated at
> >>> least twice now, continuing when
41 matches
Mail list logo
