From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev,
linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
linux-mm@kvack.org, linux-perf-users@vger.kernel.org,
linux-fsdevel@vger.kernel.org, x86@kernel.org,
Arnd Bergmann <arnd@arndb.de>,
Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast
Date: Wed, 27 Mar 2024 16:39:45 +0100 [thread overview]
Message-ID: <3922460a-4d01-4ecb-b8c5-7c57fd46f3fd@redhat.com> (raw)
In-Reply-To: <ZgQ5hNltQ2DHQXps@x1n>
On 27.03.24 16:21, Peter Xu wrote:
> On Wed, Mar 27, 2024 at 02:05:35PM +0100, David Hildenbrand wrote:
>> Some cleanups around function names, comments and the config option of
>> "GUP-fast" -- GUP without "lock" safety belts on.
>>
>> With this cleanup it's easy to judge which functions are GUP-fast specific.
>> We now consistently call it "GUP-fast", avoiding mixing it with "fast GUP",
>> "lockless", or simply "gup" (which I always considered confusing in the
>> ode).
>>
>> So the magic now happens in functions that contain "gup_fast", whereby
>> gup_fast() is the entry point into that magic. Comments consistently
>> reference either "GUP-fast" or "gup_fast()".
>>
>> Based on mm-unstable from today. I won't CC arch maintainers, but only
>> arch mailing lists, to reduce noise.
>>
>> Tested on x86_64, cross compiled on a bunch of archs, whereby some of them
>> don't properly even compile on mm-unstable anymore in my usual setup
>> (alpha, arc, parisc64, sh) ... maybe the cross compilers are outdated,
>> but there are no new ones around. Hm.
>
> I'm not sure what config you tried there; as I am doing some build tests
> recently, I found turning off CONFIG_SAMPLES + CONFIG_GCC_PLUGINS could
> avoid a lot of issues, I think it's due to libc missing. But maybe not the
> case there.
CCin Arnd; I use some of his compiler chains, others from Fedora directly. For
example for alpha and arc, the Fedora gcc is "13.2.1".
I compile quite some targets, usually with defconfig. From my compile script:
# COMPILER NAME ARCH CROSS_COMPILE CONFIG(if different from defconfig)
compile_gcc "alpha" "alpha" "alpha-linux-gnu-"
compile_gcc "arc" "arc" "arc-linux-gnu-"
compile_gcc "arm" "arm" "arm-linux-gnu-" "axm55xx_defconfig"
compile_gcc "arm-nommu" "arm" "arm-linux-gnu-" "imxrt_defconfig"
compile_gcc "arm64" "arm64" "aarch64-linux-gnu-"
compile_gcc "csky" "csky" "../cross/gcc-13.2.0-nolibc/csky-linux/bin/csky-linux-"
compile_gcc "loongarch" "loongarch" "../cross/gcc-13.2.0-nolibc/loongarch64-linux/bin/loongarch64-linux-"
compile_gcc "m68k-nommu" "m68k" "m68k-linux-gnu-" "amcore_defconfig"
compile_gcc "m68k-sun3" "m68k" "m68k-linux-gnu-" "sun3_defconfig"
compile_gcc "m68k-coldfire" "m68k" "m68k-linux-gnu-" "m5475evb_defconfig"
compile_gcc "m68k-virt" "m68k" "m68k-linux-gnu-" "virt_defconfig"
compile_gcc "microblaze" "microblaze" "microblaze-linux-gnu-"
compile_gcc "mips64" "mips" "mips64-linux-gnu-" "bigsur_defconfig"
compile_gcc "mips32-xpa" "mips" "mips64-linux-gnu-" "maltaup_xpa_defconfig"
compile_gcc "mips32-alchemy" "mips" "mips64-linux-gnu-" "gpr_defconfig"
compile_gcc "mips32" "mips" "mips64-linux-gnu-"
compile_gcc "nios2" "nios2" "nios2-linux-gnu-" "3c120_defconfig"
compile_gcc "openrisc" "openrisc" "../cross/gcc-13.2.0-nolibc/or1k-linux/bin/or1k-linux-" "virt_defconfig"
compile_gcc "parisc32" "parisc" "hppa-linux-gnu-" "generic-32bit_defconfig"
compile_gcc "parisc64" "parisc" "hppa64-linux-gnu-" "generic-64bit_defconfig"
compile_gcc "riscv32" "riscv" "riscv64-linux-gnu-" "32-bit.config"
compile_gcc "riscv64" "riscv" "riscv64-linux-gnu-" "64-bit.config"
compile_gcc "riscv64-nommu" "riscv" "riscv64-linux-gnu-" "nommu_virt_defconfig"
compile_gcc "s390x" "s390" "s390x-linux-gnu-"
compile_gcc "sh" "sh" "../cross/gcc-13.2.0-nolibc/sh4-linux/bin/sh4-linux-"
compile_gcc "sparc32" "sparc" "../cross/gcc-13.2.0-nolibc/sparc-linux/bin/sparc-linux-" "sparc32_defconfig"
compile_gcc "sparc64" "sparc" "../cross/gcc-13.2.0-nolibc/sparc64-linux/bin/sparc64-linux-" "sparc64_defconfig"
compile_gcc "uml64" "um" "" "x86_64_defconfig"
compile_gcc "x86" "x86" "" "i386_defconfig"
compile_gcc "x86-pae" "x86" "" "i386_defconfig"
compile_gcc "x86_64" "x86" ""
compile_gcc "xtensa" "xtensa" "../cross/gcc-13.2.0-nolibc/xtensa-linux/bin/xtensa-linux-" "virt_defconfig"
compile_gcc "powernv" "powerpc" "../cross/gcc-13.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux-" "powernv_defconfig"
compile_gcc "pseries" "powerpc" "../cross/gcc-13.2.0-nolibc/powerpc64-linux/bin/powerpc64-linux-" "pseries_defconfig"
Some of them look like mm-unstable issue, For example, arm64 fails with
CC arch/arm64/mm/extable.o
In file included from ./include/linux/hugetlb.h:828,
from security/commoncap.c:19:
./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of 'arch_clear_hugetlb_flags'
25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
| ^~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/hugetlb.h:840:20: note: in expansion of macro 'arch_clear_hugetlb_flags'
840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
| ^~~~~~~~~~~~~~~~~~~~~~~~
./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of 'arch_clear_hugetlb_flags' with t
ype 'void(struct folio *)'
21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./include/linux/hugetlb.h:828,
from mm/filemap.c:37:
./arch/arm64/include/asm/hugetlb.h:25:34: error: redefinition of 'arch_clear_hugetlb_flags'
25 | #define arch_clear_hugetlb_flags arch_clear_hugetlb_flags
| ^~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/hugetlb.h:840:20: note: in expansion of macro 'arch_clear_hugetlb_flags'
840 | static inline void arch_clear_hugetlb_flags(struct folio *folio) { }
| ^~~~~~~~~~~~~~~~~~~~~~~~
./arch/arm64/include/asm/hugetlb.h:21:20: note: previous definition of 'arch_clear_hugetlb_flags' with type 'void(struct folio *)'
21 | static inline void arch_clear_hugetlb_flags(struct folio *folio)
But there is other stuff like (arc):
./arch/arc/include/asm/mmu-arcv2.h: In function 'mmu_setup_asid':
./arch/arc/include/asm/mmu-arcv2.h:82:9: error: implicit declaration of function 'write_aux_reg' [-Werro
r=implicit-function-declaration]
82 | write_aux_reg(ARC_REG_PID, asid | MMU_ENABLE);
| ^~~~~~~~~~~~~
or (alpha)
WARNING: modpost: "saved_config" [vmlinux] is COMMON symbol
ERROR: modpost: "memcpy" [fs/reiserfs/reiserfs.ko] undefined!
ERROR: modpost: "memcpy" [fs/nfs/nfs.ko] undefined!
ERROR: modpost: "memcpy" [fs/nfs/nfsv3.ko] undefined!
ERROR: modpost: "memcpy" [fs/nfsd/nfsd.ko] undefined!
ERROR: modpost: "memcpy" [fs/lockd/lockd.ko] undefined!
ERROR: modpost: "memcpy" [crypto/crypto.ko] undefined!
ERROR: modpost: "memcpy" [crypto/crypto_algapi.ko] undefined!
ERROR: modpost: "memcpy" [crypto/aead.ko] undefined!
ERROR: modpost: "memcpy" [crypto/crypto_skcipher.ko] undefined!
ERROR: modpost: "memcpy" [crypto/seqiv.ko] undefined!
>
> The series makes sense to me, the naming is confusing. Btw, thanks for
> posting this as RFC. This definitely has a conflict with the other gup
> series that I had; I'll post v4 of that shortly.
Yes, I will rebase on top of that!
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-03-27 15:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-27 13:05 [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast David Hildenbrand
2024-03-27 13:05 ` [PATCH RFC 1/3] mm/gup: consistently name GUP-fast functions David Hildenbrand
2024-03-27 13:52 ` Jason Gunthorpe
2024-03-27 13:56 ` David Hildenbrand
2024-03-27 14:43 ` Mike Rapoport
2024-03-27 13:05 ` [PATCH RFC 2/3] mm/treewide: rename CONFIG_HAVE_FAST_GUP to CONFIG_HAVE_GUP_FAST David Hildenbrand
2024-03-27 15:02 ` Mike Rapoport
2024-03-27 13:05 ` [PATCH RFC 3/3] mm: use "GUP-fast" instead "fast GUP" in remaining comments David Hildenbrand
2024-03-27 15:03 ` Mike Rapoport
2024-03-27 15:21 ` [PATCH RFC 0/3] mm/gup: consistently call it GUP-fast Peter Xu
2024-03-27 15:39 ` David Hildenbrand [this message]
2024-03-27 15:46 ` Ryan Roberts
2024-03-27 15:47 ` David Hildenbrand
2024-03-27 16:22 ` Arnd Bergmann
2024-03-28 5:51 ` Vineet Gupta
2024-03-28 6:09 ` Arnd Bergmann
2024-03-28 7:15 ` Mike Rapoport
2024-03-28 9:50 ` David Hildenbrand
2024-03-28 17:46 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3922460a-4d01-4ecb-b8c5-7c57fd46f3fd@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).