Re: Please test: unlock mprotect/mmap/munmap
I concur, my 8-cores laptop (amd64) is happy with this patch. Mostly using ungoogled-chromium, mutt, ncspot, xterm along with a few vmd guests as dev machines. No isuses to report. Jesper Wallin On Tue, Nov 08, 2022 at 09:55:36AM +, Stefan Hagen wrote: > Martin Pieuchot wrote (2022-11-06 10:54 WET): > > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > > will reduce contention a lot. I'd be happy to hear from test reports > > on many architectures and possible workloads. > > My two amd64 machines are happy with it for two days now. With several > kernel builds and regular desktop use (browsers and such). > > Best Regards, > Stefan >
Re: Please test: unlock mprotect/mmap/munmap
I have now been running it for two days, I *thought * had one hang a day ago, with chrome and local building churning away with me mashing on the editor.. but I’ve now been doing the same thing with witness on for a day and had no issues. So I think whatever I might have seen is not reproducible or unrelated.. Ok beck@ > On Nov 8, 2022, at 10:30 AM, Martin Pieuchot wrote: > > On 08/11/22(Tue) 11:12, Mark Kettenis wrote: >>> Date: Tue, 8 Nov 2022 10:32:14 +0100 >>> From: Christian Weisgerber >>> >>> Martin Pieuchot: >>> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This will reduce contention a lot. I'd be happy to hear from test reports on many architectures and possible workloads. >>> >>> This survived a full amd64 package build. >> >> \8/ >> >> I think that means it should be comitted. > > I agree. This has been tested on i386, riscv64, m88k, arm64, amd64 (of > course) and sparc64. I'm pretty confident. >
Re: Please test: unlock mprotect/mmap/munmap
On Tue, Nov 08, 2022 at 10:30:47AM +, Martin Pieuchot wrote: > On 08/11/22(Tue) 11:12, Mark Kettenis wrote: > > I think that means it should be comitted. > > I agree. This has been tested on i386, riscv64, m88k, arm64, amd64 (of > course) and sparc64. I'm pretty confident. OK kn
Re: Please test: unlock mprotect/mmap/munmap
On 08/11/22(Tue) 11:12, Mark Kettenis wrote: > > Date: Tue, 8 Nov 2022 10:32:14 +0100 > > From: Christian Weisgerber > > > > Martin Pieuchot: > > > > > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > > > will reduce contention a lot. I'd be happy to hear from test reports > > > on many architectures and possible workloads. > > > > This survived a full amd64 package build. > > \8/ > > I think that means it should be comitted. I agree. This has been tested on i386, riscv64, m88k, arm64, amd64 (of course) and sparc64. I'm pretty confident.
Re: Please test: unlock mprotect/mmap/munmap
> Date: Tue, 8 Nov 2022 10:32:14 +0100 > From: Christian Weisgerber > > Martin Pieuchot: > > > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > > will reduce contention a lot. I'd be happy to hear from test reports > > on many architectures and possible workloads. > > This survived a full amd64 package build. \8/ I think that means it should be comitted.
Re: Please test: unlock mprotect/mmap/munmap
Martin Pieuchot wrote (2022-11-06 10:54 WET): > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > will reduce contention a lot. I'd be happy to hear from test reports > on many architectures and possible workloads. My two amd64 machines are happy with it for two days now. With several kernel builds and regular desktop use (browsers and such). Best Regards, Stefan
Re: Please test: unlock mprotect/mmap/munmap
Martin Pieuchot: > These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This > will reduce contention a lot. I'd be happy to hear from test reports > on many architectures and possible workloads. This survived a full amd64 package build. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: Please test: unlock mprotect/mmap/munmap
On Sun, Nov 06, 2022 at 11:54:13AM +0100, Martin Pieuchot wrote:
> These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
> will reduce contention a lot. I'd be happy to hear from test reports
> on many architectures and possible workloads.
>
> Do not forget to run "make syscalls" before building the kernel.
>
> Index: syscalls.master
> ===
> RCS file: /cvs/src/sys/kern/syscalls.master,v
> retrieving revision 1.234
> diff -u -p -r1.234 syscalls.master
> --- syscalls.master 25 Oct 2022 16:10:31 - 1.234
> +++ syscalls.master 6 Nov 2022 10:50:45 -
> @@ -126,7 +126,7 @@
> struct sigaction *osa); }
> 47 STD NOLOCK { gid_t sys_getgid(void); }
> 48 STD NOLOCK { int sys_sigprocmask(int how, sigset_t mask); }
> -49 STD { void *sys_mmap(void *addr, size_t len, int prot, \
> +49 STD NOLOCK { void *sys_mmap(void *addr, size_t len, int prot, \
> int flags, int fd, off_t pos); }
> 50 STD { int sys_setlogin(const char *namebuf); }
> #ifdef ACCOUNTING
> @@ -171,8 +171,8 @@
> const struct kevent *changelist, int nchanges, \
> struct kevent *eventlist, int nevents, \
> const struct timespec *timeout); }
> -73 STD { int sys_munmap(void *addr, size_t len); }
> -74 STD { int sys_mprotect(void *addr, size_t len, \
> +73 STD NOLOCK { int sys_munmap(void *addr, size_t len); }
> +74 STD NOLOCK { int sys_mprotect(void *addr, size_t len, \
> int prot); }
> 75 STD { int sys_madvise(void *addr, size_t len, \
> int behav); }
>
FWIW, this improves build performance by over 12% here locally.
-ml
Please test: unlock mprotect/mmap/munmap
These 3 syscalls should now be ready to run w/o KERNEL_LOCK(). This
will reduce contention a lot. I'd be happy to hear from test reports
on many architectures and possible workloads.
Do not forget to run "make syscalls" before building the kernel.
Index: syscalls.master
===
RCS file: /cvs/src/sys/kern/syscalls.master,v
retrieving revision 1.234
diff -u -p -r1.234 syscalls.master
--- syscalls.master 25 Oct 2022 16:10:31 - 1.234
+++ syscalls.master 6 Nov 2022 10:50:45 -
@@ -126,7 +126,7 @@
struct sigaction *osa); }
47 STD NOLOCK { gid_t sys_getgid(void); }
48 STD NOLOCK { int sys_sigprocmask(int how, sigset_t mask); }
-49 STD { void *sys_mmap(void *addr, size_t len, int prot, \
+49 STD NOLOCK { void *sys_mmap(void *addr, size_t len, int prot, \
int flags, int fd, off_t pos); }
50 STD { int sys_setlogin(const char *namebuf); }
#ifdef ACCOUNTING
@@ -171,8 +171,8 @@
const struct kevent *changelist, int nchanges, \
struct kevent *eventlist, int nevents, \
const struct timespec *timeout); }
-73 STD { int sys_munmap(void *addr, size_t len); }
-74 STD { int sys_mprotect(void *addr, size_t len, \
+73 STD NOLOCK { int sys_munmap(void *addr, size_t len); }
+74 STD NOLOCK { int sys_mprotect(void *addr, size_t len, \
int prot); }
75 STD { int sys_madvise(void *addr, size_t len, \
int behav); }
