On 4/14/21 11:40 AM, Christophe Leroy wrote:
>
>
> Le 14/04/2021 à 07:59, Anshuman Khandual a écrit :
>>
>>
>> On 4/14/21 10:52 AM, Christophe Leroy wrote:
>>>
>>>
>>> Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating
allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a003-20210414
i386 randconfig-a006-20210414
i386 randconfig-a004-20210414
i386 randconfig-a001-20210414
i386
defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
i386 randconfig-a003-20210414
i386 randconfig-a006-20210414
i386
Christophe Leroy writes:
> Le 08/04/2021 à 16:06, Nathan Lynch a écrit :
>> This is a reroll of the series posted here:
>> https://lore.kernel.org/linuxppc-dev/20210114220004.1138993-1-nath...@linux.ibm.com/
>>
>> Originally this work was prompted by failures on radix MMU PowerVM
>> guests when
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/macintosh/via-pmu.c:190:12: warning: '__fake_sleep' defined but not
used [-Wunused-variable]
190 | static int __fake_sleep;
|^~~~
Introduced by
From: Matthew Wilcox
> Sent: 14 April 2021 22:36
>
> On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> > (If others want to reproduce). First I could not reproduce on ARM32.
> > Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> > cause the issue by
On Wed, Apr 14, 2021 at 09:13:22PM +0200, Jesper Dangaard Brouer wrote:
> (If others want to reproduce). First I could not reproduce on ARM32.
> Then I found out that enabling CONFIG_XEN on ARCH=arm was needed to
> cause the issue by enabling CONFIG_ARCH_DMA_ADDR_T_64BIT.
hmmm ... you should be
On Wed, Apr 14, 2021 at 5:40 AM Vaibhav Jain wrote:
>
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC. The error is of the form below:
>
> papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to
On Wed, Apr 14, 2021 at 09:51:40PM +0530, Vaibhav Jain wrote:
> Thanks for looking into this patch Ira,
>
> Ira Weiny writes:
>
> > On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
> >> Currently drc_pmem_qeury_stats() generates a dev_err in case
> >> "Enable Performance
On Wed, 14 Apr 2021 12:50:52 +0100
Matthew Wilcox wrote:
> > That said, I think we need to have a quicker fix for the immediate
> > issue with 64-bit bit dma_addr on 32-bit arch and the misalignment hole
> > it leaves[3] in struct page. In[3] you mention ppc32, does it only
> > happens on
On Wed, Apr 14, 2021 at 03:32:04PM +, David Laight wrote:
> From: Segher Boessenkool
> > Sent: 14 April 2021 16:19
> ...
> > > Could the kernel use GCC builtin atomic functions instead ?
> > >
> > > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
> >
> > Certainly that
Le 08/04/2021 à 16:06, Nathan Lynch a écrit :
This is a reroll of the series posted here:
https://lore.kernel.org/linuxppc-dev/20210114220004.1138993-1-nath...@linux.ibm.com/
Originally this work was prompted by failures on radix MMU PowerVM
guests when passing buffers to RTAS that lay
Now that atomic_add() and atomic_sub() handle immediate operands,
atomic_inc() and atomic_dec() have no added value compared to the
generic fallback which calls atomic_add(1) and atomic_sub(1).
Also remove atomic_inc_not_zero() which fallsback to
atomic_add_unless() which itself fallsback to
Today we get the following code generation for atomic operations:
c001bb2c: 39 20 00 01 li r9,1
c001bb30: 7d 40 18 28 lwarx r10,0,r3
c001bb34: 7d 09 50 50 subfr8,r9,r10
c001bb38: 7d 00 19 2d stwcx. r8,0,r3
Today we get the following code generation for bitops like
set or clear bit:
c0009fe0: 39 40 08 00 li r10,2048
c0009fe4: 7c e0 40 28 lwarx r7,0,r8
c0009fe8: 7c e7 53 78 or r7,r7,r10
c0009fec: 7c e0 41 2d stwcx.
Thanks for looking into this patch Ira,
Ira Weiny writes:
> On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
>> Currently drc_pmem_qeury_stats() generates a dev_err in case
>> "Enable Performance Information Collection" feature is disabled from
>> HMC. The error is of the form
> Doing this fixes it:
>
> +++ b/include/linux/types.h
> @@ -140,7 +140,7 @@ typedef u64 blkcnt_t;
> * so they don't care about the size of the actual bus addresses.
> */
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
> -typedef u64 dma_addr_t;
> +typedef u64 __attribute__((aligned(sizeof(void *
On Wed, Apr 14, 2021 at 06:10:26PM +0530, Vaibhav Jain wrote:
> Currently drc_pmem_qeury_stats() generates a dev_err in case
> "Enable Performance Information Collection" feature is disabled from
> HMC. The error is of the form below:
>
> papr_scm ibm,persistent-memory:ibm,pmemory@44104001:
From: Segher Boessenkool
> Sent: 14 April 2021 16:19
...
> > Could the kernel use GCC builtin atomic functions instead ?
> >
> > https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>
> Certainly that should work fine for the simpler cases that the atomic
> operations are meant to
On Wed, Apr 14, 2021 at 02:42:51PM +0200, Christophe Leroy wrote:
> Le 14/04/2021 à 14:24, Segher Boessenkool a écrit :
> >On Wed, Apr 14, 2021 at 12:01:21PM +1000, Nicholas Piggin wrote:
> >>Would be nice if we could let the compiler deal with it all...
> >>
> >>static inline unsigned long
When probe_kernel_read_inst() was created, there was no good place to
put it, so a file called lib/inst.c was dedicated for it.
Since then, probe_kernel_read_inst() has been renamed
copy_from_kernel_nofault_inst(). And mm/maccess.h didn't exist at that
time. Today, mm/maccess.h is related to
Its name comes from former probe_user_read() function.
That function is now called copy_from_user_nofault().
probe_user_read_inst() uses copy_from_user_nofault() to read only
a few bytes. It is suboptimal.
It does the same as get_user_inst() but in addition disables
page faults.
But on the
When probe_kernel_read_inst() was created, it was to mimic
probe_kernel_read() function.
Since then, probe_kernel_read() has been renamed
copy_from_kernel_nofault().
Rename probe_kernel_read_inst() into copy_inst_from_kernel_nofault().
Signed-off-by: Christophe Leroy
---
v3:
We have two independant versions of probe_kernel_read_inst(), one for
PPC32 and one for PPC64.
The PPC32 is identical to the first part of the PPC64 version.
The remaining part of PPC64 version is not relevant for PPC32, but
not contradictory, so we can easily have a common function with
the
Le 14/04/2021 à 07:23, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
When probe_kernel_read_inst() was created, it was to mimic
probe_kernel_read() function.
Since then, probe_kernel_read() has been renamed
copy_from_kernel_nofault().
Rename probe_kernel_read_inst() into
Hi Dan,
Am 2021-04-14 07:33, schrieb Dan Carpenter:
url:
https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030
base:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
Le 14/04/2021 à 14:24, Segher Boessenkool a écrit :
On Wed, Apr 14, 2021 at 12:01:21PM +1000, Nicholas Piggin wrote:
Would be nice if we could let the compiler deal with it all...
static inline unsigned long lr(unsigned long *mem)
{
unsigned long val;
/*
* This
Currently drc_pmem_qeury_stats() generates a dev_err in case
"Enable Performance Information Collection" feature is disabled from
HMC. The error is of the form below:
papr_scm ibm,persistent-memory:ibm,pmemory@44104001: Failed to query
performance stats, Err:-10
This error message
On Wed, Apr 14, 2021 at 12:01:21PM +1000, Nicholas Piggin wrote:
> Would be nice if we could let the compiler deal with it all...
>
> static inline unsigned long lr(unsigned long *mem)
> {
> unsigned long val;
>
> /*
> * This doesn't clobber memory but want to avoid
On Wed, Apr 14, 2021 at 12:50:52PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 14, 2021 at 10:10:44AM +0200, Jesper Dangaard Brouer wrote:
> > Yes, indeed! - And very frustrating. It's keeping me up at night.
> > I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
> > me that I
On Wed, Apr 14, 2021 at 10:10:44AM +0200, Jesper Dangaard Brouer wrote:
> Yes, indeed! - And very frustrating. It's keeping me up at night.
> I'm dreaming about 32 vs 64 bit data structures. My fitbit stats tell
> me that I don't sleep well with these kind of dreams ;-)
Then you're going to love
From: Xiongwei Song
Define macros to list ppc interrupt types in interttupt.h, replace the
reference of the trap hex values with these macros.
Referred the hex numbers in arch/powerpc/kernel/exceptions-64e.S,
arch/powerpc/kernel/exceptions-64s.S, arch/powerpc/kernel/head_*.S,
Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.
The alpha, microblaze and
On Wed, 14 Apr 2021 17:27:57 +0800
Jisheng Zhang wrote:
> CAUTION: Email originated externally, do not click links or open attachments
> unless you recognize the sender and know the content is safe.
>
>
> On Wed, 14 Apr 2021 11:10:42 +0200
> Christophe Leroy wrote:
>
> >
> > Le 14/04/2021 à
On Wed, 14 Apr 2021 11:10:42 +0200
Christophe Leroy wrote:
>
> Le 14/04/2021 à 10:58, Jisheng Zhang a écrit :
> > Many architectures implement the trap_init() as NOP, since there is
> > no such default for trap_init(), this empty stub is duplicated among
> > these architectures. Provide a
"Aneesh Kumar K.V" writes:
> Vaibhav Jain writes:
>
>> Hi Shiva,
>>
>> Apologies for a late review but something just caught my eye while
>> working on a different patch.
>>
>> Shivaprasad G Bhat writes:
>>
>>> Add support for ND_REGION_ASYNC capability if the device tree
>>> indicates
Le 14/04/2021 à 10:58, Jisheng Zhang a écrit :
Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in
mremap HAVE_MOVE_PMD/PUD optimization time comparison for 1GB region:
1GB mremap - Source PTE-aligned, Destination PTE-aligned
mremap time: 1127034ns
1GB mremap - Source PMD-aligned, Destination PMD-aligned
mremap time: 508817ns
1GB mremap - Source PUD-aligned, Destination
Architectures like ppc64 support faster mremap only with radix
translation. Hence allow a runtime check w.r.t support for fast mremap.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/tlb.h | 6 ++
mm/mremap.c| 15 ++-
2 files changed, 20
Move TLB flush outside page table lock so that kernel does
less with page table lock held. Releasing the ptl with old
TLB contents still valid will behave such that such access
happened before the level3 or level2 entry update.
Signed-off-by: Aneesh Kumar K.V
---
mm/mremap.c | 8
1
Some architectures do have the concept of page walk cache which need
to be flush when updating higher levels of page tables. A fast mremap
that involves moving page table pages instead of copying pte entries
should flush page walk cache since the old translation cache is no more
valid.
Add new
Update _tlbiel_pid() such that we can avoid build errors like below when
using this function in other places.
arch/powerpc/mm/book3s64/radix_tlb.c: In function
‘__radix__flush_tlb_range_psize’:
arch/powerpc/mm/book3s64/radix_tlb.c:114:2: warning: ‘asm’ operand 3 probably
does not match
Signed-off-by: Aneesh Kumar K.V
---
.../include/asm/book3s/64/tlbflush-radix.h| 19 +++-
arch/powerpc/include/asm/book3s/64/tlbflush.h | 23 ---
arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 4 +--
arch/powerpc/mm/book3s64/radix_tlb.c | 29 +++
pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures like ppc64 do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.
Signed-off-by:
With a large mmap map size, we can overlap with the text area and using
MAP_FIXED results in unmapping that area. Switch to MAP_FIXED_NOREPLACE
and handle the EEXIST error.
Reviewed-by: Kalesh Singh
Signed-off-by: Aneesh Kumar K.V
---
tools/testing/selftests/vm/mremap_test.c | 5 +++--
1 file
Instead of hardcoding 4K page size fetch it using sysconf(). For the performance
measurements test still assume 2M and 1G are hugepage sizes.
Reviewed-by: Kalesh Singh
Signed-off-by: Aneesh Kumar K.V
---
tools/testing/selftests/vm/mremap_test.c | 113 ---
1 file changed, 61
Hi,
This patchset enables MOVE_PMD/MOVE_PUD support on power. This requires
the platform to support updating higher-level page tables without
updating page table entries. This also needs to invalidate the Page Walk
Cache on architecture supporting the same.
Changes from v3:
* Fix build error
Many architectures implement the trap_init() as NOP, since there is
no such default for trap_init(), this empty stub is duplicated among
these architectures. Provide a generic but weak NOP implementation
to drop the empty stubs of trap_init() in these architectures.
Signed-off-by: Jisheng Zhang
Hi Michael,
url:
https://github.com/0day-ci/linux/commits/Michael-Walle/of-net-support-non-platform-devices-in-of_get_mac_address/20210406-234030
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
cc0626c2aaed8e475efdd85fa374b497a7192e35
config:
On 2021-04-13 10:53:39 Tue, Oliver O'Halloran wrote:
> On Mon, Apr 12, 2021 at 5:52 PM Mahesh Salgaonkar
> wrote:
> >
> > During the EEH MMIO error checking, the current implementation fails to map
> > the (virtual) MMIO address back to the pci device on radix with hugepage
> > mappings for I/O.
On Mon, 12 Apr 2021 02:15:32 +0100
Matthew Wilcox wrote:
> On Sun, Apr 11, 2021 at 11:33:18AM +0100, Matthew Wilcox wrote:
> > Basically, we have three aligned dwords here. We can either alias with
> > @flags and the first word of @lru, or the second word of @lru and @mapping,
> > or @index and
On Mon, Apr 12, 2021 at 06:33:55PM +0200, Michal Suchánek wrote:
> On Mon, Apr 12, 2021 at 04:24:44PM +0100, Mel Gorman wrote:
> > On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > > Peter, Valentin, Vincent, Mel, etal
> > > > >
> > > > > On architectures where we have
Hello Mel,
On Mon, Apr 12, 2021 at 04:24:44PM +0100, Mel Gorman wrote:
> On Mon, Apr 12, 2021 at 02:21:47PM +0200, Vincent Guittot wrote:
> > > > Peter, Valentin, Vincent, Mel, etal
> > > >
> > > > On architectures where we have multiple levels of cache access latencies
> > > > within a DIE, (For
Hi Arnd,
On Mon, 12 Apr 2021 11:55:41 +0200 Arnd Bergmann wrote:
>
> On Mon, Apr 12, 2021 at 10:55 AM Christoph Hellwig wrote:
> >
> > Signed-off-by: Christoph Hellwig
>
> The patch looks good, but I'd like to see a description for each one.
> How about:
>
> | The check was added when
Le 14/04/2021 à 07:59, Anshuman Khandual a écrit :
On 4/14/21 10:52 AM, Christophe Leroy wrote:
Le 14/04/2021 à 04:54, Anshuman Khandual a écrit :
Currently most platforms define FIRST_USER_ADDRESS as 0UL duplicating the
same code all over. Instead define a new option
55 matches
Mail list logo
