Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
On Thu, Feb 14, 2019 at 06:56:42PM +1100, Bruce Evans wrote: > I don't understand how pbuf_preallocate() allocates for the other > pbuf pools. When I debugged this for clpbufs, the preallocation was > not used. pbuf types other than clpbufs seem to be unused in my > configurations. I thought that pbufs were used during initialization, > since they end up with a nonzero FREE count, but their only use seems > to be to preallocate them. vnode_pager_generic_getpages() typically not used for UFS on modern systems. Instead the buffer pager is active which does not need pbufs, it uses real buffers coherent with the UFS buffer cache. To get to the actual use of pbufs now you can: - perform clustered buffer io; - use vnode-backed md(4) (this case is still broken if md(4) is loaded as a module); - cause system swapping; - use sendfile(2). ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344115 - head
Author: avos Date: Thu Feb 14 09:21:19 2019 New Revision: 344115 URL: https://svnweb.freebsd.org/changeset/base/344115 Log: Add UPDATING entry for IEEE80211_AMPDU_AGE and AH_SUPPORT_AR5416 options removal Notified by: ian Modified: head/UPDATING Modified: head/UPDATING == --- head/UPDATING Thu Feb 14 09:12:19 2019(r344114) +++ head/UPDATING Thu Feb 14 09:21:19 2019(r344115) @@ -38,6 +38,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: modules on kernels not having 'device iflib', the iflib.ko module is loaded automatically. +20190125: + The IEEE80211_AMPDU_AGE and AH_SUPPORT_AR5416 kernel configuration + options no longer exist since r343219 and r343427 respectively; + nothing uses them, so they should be just removed from custom + kernel config files. + 20181230: r342635 changes the way efibootmgr(8) works by requiring users to add the -b (bootnum) parameter for commands where the bootnum was previously ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344118 - head/sys/i386/include
Author: kib
Date: Thu Feb 14 13:53:11 2019
New Revision: 344118
URL: https://svnweb.freebsd.org/changeset/base/344118
Log:
Provide userspace versions of do_cpuid() and cpuid_count() on i386.
Some older compilers, when generating PIC code, cannot handle inline
asm that clobbers %ebx (because %ebx is used as the GOT offset
register). Userspace versions avoid clobbering %ebx by saving it to
stack before executing the CPUID instruction.
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/sys/i386/include/cpufunc.h
Modified: head/sys/i386/include/cpufunc.h
==
--- head/sys/i386/include/cpufunc.h Thu Feb 14 09:50:59 2019
(r344117)
+++ head/sys/i386/include/cpufunc.h Thu Feb 14 13:53:11 2019
(r344118)
@@ -108,21 +108,47 @@ disable_intr(void)
__asm __volatile("cli" : : : "memory");
}
+#ifdef _KERNEL
static __inline void
do_cpuid(u_int ax, u_int *p)
{
__asm __volatile("cpuid"
-: "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
-: "0" (ax));
+ : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
+ : "0" (ax));
}
static __inline void
cpuid_count(u_int ax, u_int cx, u_int *p)
{
__asm __volatile("cpuid"
-: "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
-: "0" (ax), "c" (cx));
+ : "=a" (p[0]), "=b" (p[1]), "=c" (p[2]), "=d" (p[3])
+ : "0" (ax), "c" (cx));
}
+#else
+static __inline void
+do_cpuid(u_int ax, u_int *p)
+{
+ __asm __volatile(
+ "pushl\t%%ebx\n\t"
+ "cpuid\n\t"
+ "movl\t%%ebx,%1\n\t"
+ "popl\t%%ebx"
+ : "=a" (p[0]), "=DS" (p[1]), "=c" (p[2]), "=d" (p[3])
+ : "0" (ax));
+}
+
+static __inline void
+cpuid_count(u_int ax, u_int cx, u_int *p)
+{
+ __asm __volatile(
+ "pushl\t%%ebx\n\t"
+ "cpuid\n\t"
+ "movl\t%%ebx,%1\n\t"
+ "popl\t%%ebx"
+ : "=a" (p[0]), "=DS" (p[1]), "=c" (p[2]), "=d" (p[3])
+ : "0" (ax), "c" (cx));
+}
+#endif
static __inline void
enable_intr(void)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344119 - head/lib/libc/x86/sys
Author: kib
Date: Thu Feb 14 13:59:00 2019
New Revision: 344119
URL: https://svnweb.freebsd.org/changeset/base/344119
Log:
x86 __vdso_gettc(): use machine/cpufunc.h function for CPUID.
Based on the discussion with: jkim
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Modified:
head/lib/libc/x86/sys/__vdso_gettc.c
Modified: head/lib/libc/x86/sys/__vdso_gettc.c
==
--- head/lib/libc/x86/sys/__vdso_gettc.cThu Feb 14 13:53:11 2019
(r344118)
+++ head/lib/libc/x86/sys/__vdso_gettc.cThu Feb 14 13:59:00 2019
(r344119)
@@ -54,31 +54,6 @@ __FBSDID("$FreeBSD$");
#include "libc_private.h"
static void
-cpuidp(u_int leaf, u_int p[4])
-{
-
- __asm __volatile(
-#if defined(__i386__)
- " pushl %%ebx\n"
-#endif
- " cpuid\n"
-#if defined(__i386__)
- " movl%%ebx,%1\n"
- " popl%%ebx"
-#endif
- : "=a" (p[0]),
-#if defined(__i386__)
- "=r" (p[1]),
-#elif defined(__amd64__)
- "=b" (p[1]),
-#else
-#error "Arch"
-#endif
- "=c" (p[2]), "=d" (p[3])
- : "0" (leaf));
-}
-
-static void
rdtsc_mb_lfence(void)
{
@@ -100,12 +75,12 @@ rdtsc_mb_none(void)
DEFINE_UIFUNC(static, void, rdtsc_mb, (void), static)
{
u_int p[4];
- /* Not a typo, string matches our cpuidp() registers use. */
+ /* Not a typo, string matches our do_cpuid() registers use. */
static const char intel_id[] = "GenuntelineI";
if ((cpu_feature & CPUID_SSE2) == 0)
return (rdtsc_mb_none);
- cpuidp(0, p);
+ do_cpuid(0, p);
return (memcmp(p + 1, intel_id, sizeof(intel_id) - 1) == 0 ?
rdtsc_mb_lfence : rdtsc_mb_mfence);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344120 - in head/lib/libc: . amd64/gen i386/gen x86/gen
Author: kib
Date: Thu Feb 14 14:02:33 2019
New Revision: 344120
URL: https://svnweb.freebsd.org/changeset/base/344120
Log:
Unify i386 and amd64 getcontextx.c, and use ifuncs while there.
In particular, use ifuncs for __getcontextx_size(), also calculate the
size of the extended save area in resolver. Same for __fillcontextx2().
Sponsored by: The FreeBSD Foundation
MFC after:1 week
Added:
head/lib/libc/x86/gen/
head/lib/libc/x86/gen/Makefile.inc (contents, props changed)
head/lib/libc/x86/gen/getcontextx.c
- copied, changed from r344117, head/lib/libc/amd64/gen/getcontextx.c
Deleted:
head/lib/libc/amd64/gen/getcontextx.c
head/lib/libc/i386/gen/getcontextx.c
Modified:
head/lib/libc/Makefile
head/lib/libc/amd64/gen/Makefile.inc
head/lib/libc/i386/gen/Makefile.inc
Modified: head/lib/libc/Makefile
==
--- head/lib/libc/Makefile Thu Feb 14 13:59:00 2019(r344119)
+++ head/lib/libc/Makefile Thu Feb 14 14:02:33 2019(r344120)
@@ -122,6 +122,7 @@ NOASM=
.endif
.if ${LIBC_ARCH} == "i386" || ${LIBC_ARCH} == "amd64"
.include "${LIBC_SRCTOP}/x86/sys/Makefile.inc"
+.include "${LIBC_SRCTOP}/x86/gen/Makefile.inc"
.endif
.if ${MK_NIS} != "no"
CFLAGS+= -DYP
Modified: head/lib/libc/amd64/gen/Makefile.inc
==
--- head/lib/libc/amd64/gen/Makefile.incThu Feb 14 13:59:00 2019
(r344119)
+++ head/lib/libc/amd64/gen/Makefile.incThu Feb 14 14:02:33 2019
(r344120)
@@ -2,7 +2,7 @@
# $FreeBSD$
SRCS+= _setjmp.S _set_tp.c rfork_thread.S setjmp.S sigsetjmp.S \
- fabs.S getcontextx.c \
+ fabs.S \
infinity.c ldexp.c makecontext.c signalcontext.c \
flt_rounds.c fpgetmask.c fpsetmask.c fpgetprec.c fpsetprec.c \
fpgetround.c fpsetround.c fpgetsticky.c
Modified: head/lib/libc/i386/gen/Makefile.inc
==
--- head/lib/libc/i386/gen/Makefile.inc Thu Feb 14 13:59:00 2019
(r344119)
+++ head/lib/libc/i386/gen/Makefile.inc Thu Feb 14 14:02:33 2019
(r344120)
@@ -2,5 +2,5 @@
# $FreeBSD$
SRCS+= _ctx_start.S _setjmp.S _set_tp.c fabs.S \
- flt_rounds.c getcontextx.c infinity.c ldexp.c makecontext.c \
+ flt_rounds.c infinity.c ldexp.c makecontext.c \
rfork_thread.S setjmp.S signalcontext.c sigsetjmp.S
Added: head/lib/libc/x86/gen/Makefile.inc
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/lib/libc/x86/gen/Makefile.inc Thu Feb 14 14:02:33 2019
(r344120)
@@ -0,0 +1,6 @@
+# $FreeBSD$
+
+.PATH: ${LIBC_SRCTOP}/x86/gen
+
+SRCS+= \
+ getcontextx.c
Copied and modified: head/lib/libc/x86/gen/getcontextx.c (from r344117,
head/lib/libc/amd64/gen/getcontextx.c)
==
--- head/lib/libc/amd64/gen/getcontextx.c Thu Feb 14 09:50:59 2019
(r344117, copy source)
+++ head/lib/libc/x86/gen/getcontextx.c Thu Feb 14 14:02:33 2019
(r344120)
@@ -35,49 +35,76 @@ __FBSDID("$FreeBSD$");
#include
#include
#include
-#include
#include
#include
+#include
+#include
-static int xstate_sz = -1;
+#if defined __i386__
+#defineX86_GET_XFPUSTATE I386_GET_XFPUSTATE
+typedef struct savexmm savex86_t ;
+typedef struct i386_get_xfpustate x86_get_xfpustate_t;
+#elif defined __amd64__
+#defineX86_GET_XFPUSTATE AMD64_GET_XFPUSTATE
+typedef struct savefpu savex86_t;
+typedef struct amd64_get_xfpustate x86_get_xfpustate_t;
+#else
+#error "Wrong arch"
+#endif
-int
-__getcontextx_size(void)
+static int xstate_sz = 0;
+
+static int
+__getcontextx_size_xfpu(void)
{
+
+ return (sizeof(ucontext_t) + xstate_sz);
+}
+
+DEFINE_UIFUNC(, int, __getcontextx_size, (void), static)
+{
u_int p[4];
- if (xstate_sz == -1) {
- do_cpuid(1, p);
- if ((p[2] & CPUID2_OSXSAVE) != 0) {
- cpuid_count(0xd, 0x0, p);
- xstate_sz = p[1] - sizeof(struct savefpu);
- } else
- xstate_sz = 0;
+ if ((cpu_feature2 & CPUID2_OSXSAVE) != 0) {
+ cpuid_count(0xd, 0x0, p);
+ xstate_sz = p[1] - sizeof(savex86_t);
}
+ return (__getcontextx_size_xfpu);
+}
- return (sizeof(ucontext_t) + xstate_sz);
+static int
+__fillcontextx2_xfpu(char *ctx)
+{
+ x86_get_xfpustate_t xfpu;
+ ucontext_t *ucp;
+
+ ucp = (ucontext_t *)ctx;
+ xfpu.addr = (char *)(ucp + 1);
+ xfpu.len = xstate_sz;
+ if (sysarch(X86_GET_XFPUSTATE, &xfpu) == -1)
+ return (-1);
+ ucp->uc_mcontext.mc_xfpustate = (__register_t)xfpu.addr;
+ ucp->uc_mcontext.mc_xfpustate_len = xstat
svn commit: r344121 - in head/sys: arm/arm arm64/arm64 mips/mips powerpc/powerpc riscv/riscv sparc64/sparc64
Author: kib
Date: Thu Feb 14 14:44:53 2019
New Revision: 344121
URL: https://svnweb.freebsd.org/changeset/base/344121
Log:
Enable enabling ASLR on non-x86 architectures.
Discussed with: emaste
Sponsored by: The FreeBSD Foundation
Modified:
head/sys/arm/arm/elf_machdep.c
head/sys/arm64/arm64/elf_machdep.c
head/sys/mips/mips/elf_machdep.c
head/sys/powerpc/powerpc/elf32_machdep.c
head/sys/powerpc/powerpc/elf64_machdep.c
head/sys/riscv/riscv/elf_machdep.c
head/sys/sparc64/sparc64/elf_machdep.c
Modified: head/sys/arm/arm/elf_machdep.c
==
--- head/sys/arm/arm/elf_machdep.c Thu Feb 14 14:02:33 2019
(r344120)
+++ head/sys/arm/arm/elf_machdep.c Thu Feb 14 14:44:53 2019
(r344121)
@@ -84,7 +84,7 @@ struct sysentvec elf32_freebsd_sysvec = {
#if __ARM_ARCH >= 6
SV_ASLR | SV_SHP | SV_TIMEKEEP |
#endif
- SV_ABI_FREEBSD | SV_ILP32,
+ SV_ABI_FREEBSD | SV_ILP32 | SV_ASLR,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_syscallnames = syscallnames,
Modified: head/sys/arm64/arm64/elf_machdep.c
==
--- head/sys/arm64/arm64/elf_machdep.c Thu Feb 14 14:02:33 2019
(r344120)
+++ head/sys/arm64/arm64/elf_machdep.c Thu Feb 14 14:44:53 2019
(r344121)
@@ -79,7 +79,8 @@ static struct sysentvec elf64_freebsd_sysvec = {
.sv_setregs = exec_setregs,
.sv_fixlimit= NULL,
.sv_maxssiz = NULL,
- .sv_flags = SV_SHP | SV_TIMEKEEP | SV_ABI_FREEBSD | SV_LP64,
+ .sv_flags = SV_SHP | SV_TIMEKEEP | SV_ABI_FREEBSD | SV_LP64 |
+ SV_ASLR,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_syscallnames = syscallnames,
Modified: head/sys/mips/mips/elf_machdep.c
==
--- head/sys/mips/mips/elf_machdep.cThu Feb 14 14:02:33 2019
(r344120)
+++ head/sys/mips/mips/elf_machdep.cThu Feb 14 14:44:53 2019
(r344121)
@@ -76,7 +76,7 @@ struct sysentvec elf64_freebsd_sysvec = {
.sv_setregs = exec_setregs,
.sv_fixlimit= NULL,
.sv_maxssiz = NULL,
- .sv_flags = SV_ABI_FREEBSD | SV_LP64,
+ .sv_flags = SV_ABI_FREEBSD | SV_LP64 | SV_ASLR,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_syscallnames = syscallnames,
@@ -131,7 +131,7 @@ struct sysentvec elf32_freebsd_sysvec = {
.sv_setregs = exec_setregs,
.sv_fixlimit= NULL,
.sv_maxssiz = NULL,
- .sv_flags = SV_ABI_FREEBSD | SV_ILP32,
+ .sv_flags = SV_ABI_FREEBSD | SV_ILP32 | SV_ASLR,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_syscallnames = syscallnames,
Modified: head/sys/powerpc/powerpc/elf32_machdep.c
==
--- head/sys/powerpc/powerpc/elf32_machdep.cThu Feb 14 14:02:33 2019
(r344120)
+++ head/sys/powerpc/powerpc/elf32_machdep.cThu Feb 14 14:44:53 2019
(r344121)
@@ -115,7 +115,7 @@ struct sysentvec elf32_freebsd_sysvec = {
.sv_fixlimit= NULL,
#endif
.sv_maxssiz = NULL,
- .sv_flags = SV_ABI_FREEBSD | SV_ILP32 | SV_SHP,
+ .sv_flags = SV_ABI_FREEBSD | SV_ILP32 | SV_SHP | SV_ASLR,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_shared_page_base = FREEBSD32_SHAREDPAGE,
Modified: head/sys/powerpc/powerpc/elf64_machdep.c
==
--- head/sys/powerpc/powerpc/elf64_machdep.cThu Feb 14 14:02:33 2019
(r344120)
+++ head/sys/powerpc/powerpc/elf64_machdep.cThu Feb 14 14:44:53 2019
(r344121)
@@ -79,7 +79,7 @@ struct sysentvec elf64_freebsd_sysvec_v1 = {
.sv_setregs = exec_setregs_funcdesc,
.sv_fixlimit= NULL,
.sv_maxssiz = NULL,
- .sv_flags = SV_ABI_FREEBSD | SV_LP64 | SV_SHP,
+ .sv_flags = SV_ABI_FREEBSD | SV_LP64 | SV_SHP | SV_ASLR,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_syscallnames = syscallnames,
Modified: head/sys/riscv/riscv/elf_machdep.c
==
--- head/sys/riscv/riscv/elf_machdep.c Thu Feb 14 14:02:33 2019
(r344120)
+++ head/sys/riscv/riscv/elf_machdep.c Thu Feb 14 14:44:53 2019
(r344121)
@@ -
svn commit: r344123 - head/sys/powerpc/powerpc
Author: luporl
Date: Thu Feb 14 15:15:32 2019
New Revision: 344123
URL: https://svnweb.freebsd.org/changeset/base/344123
Log:
[PPC64] Fix mismatch between thread flags and MSR
When sigreturn() restored a thread's context, SRR1 was being restored
to its previous value, but pcb_flags was not being touched.
This could cause a mismatch between the thread's MSR and its pcb_flags.
For instance, when the thread used the FPU for the first time inside
the signal handler, sigreturn() would clear SRR1, but not pcb_flags.
Then, the thread would return with the FPU bit cleared in MSR and,
the next time it tried to use the FPU, it would fail on a KASSERT
that checked if the FPU was disabled.
This change clears the FPU bit in both pcb_flags and frame->srr1,
as the code that restores the context expects to use the FPU trap
to re-enable it.
PR: 234539
Reported by: sbruno
Reviewed by: jhibbits, sbruno
Differential Revision:https://reviews.freebsd.org/D19166
Modified:
head/sys/powerpc/powerpc/exec_machdep.c
Modified: head/sys/powerpc/powerpc/exec_machdep.c
==
--- head/sys/powerpc/powerpc/exec_machdep.c Thu Feb 14 14:50:47 2019
(r344122)
+++ head/sys/powerpc/powerpc/exec_machdep.c Thu Feb 14 15:15:32 2019
(r344123)
@@ -474,6 +474,10 @@ set_mcontext(struct thread *td, mcontext_t *mcp)
else
tf->fixreg[2] = tls;
+ /* Disable FPU */
+ tf->srr1 &= ~PSL_FP;
+ pcb->pcb_flags &= ~PCB_FPU;
+
if (mcp->mc_flags & _MC_FP_VALID) {
/* enable_fpu() will happen lazily on a fault */
pcb->pcb_flags |= PCB_FPREGS;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344128 - head/sys/vm
Author: kib
Date: Thu Feb 14 15:45:53 2019
New Revision: 344128
URL: https://svnweb.freebsd.org/changeset/base/344128
Log:
Make anon clustering more compatible.
Make the clustering enabling knob more fine-grained by providing a
setting where the allocation with hint is not clustered. This is aimed
to be somewhat more compatible with e.g. go 1.4 which expects that
hinted mmap without MAP_FIXED does not change the allocation address.
Now the vm.cluster_anon can be set to 1 to only cluster when no hints,
and to 2 to always cluster. Default value is 1.
Requested by: peter
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after:1 month
Differential revision:https://reviews.freebsd.org/D19194
Modified:
head/sys/vm/vm_map.c
Modified: head/sys/vm/vm_map.c
==
--- head/sys/vm/vm_map.cThu Feb 14 15:42:29 2019(r344127)
+++ head/sys/vm/vm_map.cThu Feb 14 15:45:53 2019(r344128)
@@ -1487,8 +1487,23 @@ static const int aslr_pages_rnd_32[2] = {0x100, 0x4};
static int cluster_anon = 1;
SYSCTL_INT(_vm, OID_AUTO, cluster_anon, CTLFLAG_RW,
&cluster_anon, 0,
-"Cluster anonymous mappings");
+"Cluster anonymous mappings: 0 = no, 1 = yes if no hint, 2 = always");
+static bool
+clustering_anon_allowed(vm_offset_t addr)
+{
+
+ switch (cluster_anon) {
+ case 0:
+ return (false);
+ case 1:
+ return (addr == 0);
+ case 2:
+ default:
+ return (true);
+ }
+}
+
static long aslr_restarts;
SYSCTL_LONG(_vm, OID_AUTO, aslr_restarts, CTLFLAG_RD,
&aslr_restarts, 0,
@@ -1593,7 +1608,7 @@ vm_map_find(vm_map_t map, vm_object_t object, vm_ooffs
} else
alignment = 0;
en_aslr = (map->flags & MAP_ASLR) != 0;
- update_anon = cluster = cluster_anon != 0 &&
+ update_anon = cluster = clustering_anon_allowed(*addr) &&
(map->flags & MAP_IS_SUB_MAP) == 0 && max_addr == 0 &&
find_space != VMFS_NO_SPACE && object == NULL &&
(cow & (MAP_INHERIT_SHARE | MAP_STACK_GROWS_UP |
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
On Thu, Feb 14, 2019 at 06:56:42PM +1100, Bruce Evans wrote: > On Wed, 13 Feb 2019, Justin Hibbits wrote: > > > On Tue, 15 Jan 2019 01:02:17 + (UTC) > > Gleb Smirnoff wrote: > > > >> Author: glebius > >> Date: Tue Jan 15 01:02:16 2019 > >> New Revision: 343030 > >> URL: https://svnweb.freebsd.org/changeset/base/343030 > >> > >> Log: > >> Allocate pager bufs from UMA instead of 80-ish mutex protected > >> linked list. > > ... > > > > This seems to break 32-bit platforms, or at least 32-bit book-e > > powerpc, which has a limited KVA space (~500MB). It preallocates I've > > seen over 2500 pbufs, at 128kB each, eating up over 300MB KVA, > > leaving very little left for the rest of runtime. > > Hrmph. I complained other things in this commit this when it was > committed, but not this largest bug since preallocation was broken then > so I thought that it wasn't done, so that problems are smaller unless the > excessive limits are actually reached. > > Now i386 does it: > > XX ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > XX > XX swrbuf: 336,128, 0, 0, 0, 0, 0 > XX swwbuf: 336, 64, 0, 0, 0, 0, 0 > XX nfspbuf:336,128, 0, 0, 0, 0, 0 > XX mdpbuf: 336, 25, 0, 0, 0, 0, 0 > XX clpbuf: 336,128, 0, 5, 4, 0, 0 > XX vnpbuf: 336, 2048, 0, 0, 0, 0, 0 > XX pbuf: 336, 16, 0,2535, 0, 0, 0 > > but i386 now has 4GB of KVA, with almost 3GB to waste, so the bug is not > noticed there. > > The preallocation wasn't there in my last mail to the author about nearby > bugs, on 24 Jan 2019: > > YY vnpbuf: 568, 2048, 0, 0, 0, 0, 0 > YY clpbuf: 568,128, 0, 128,8750, 0, 1 > YY pbuf: 568, 16, 0, 4, 0, 0, 0 > > This output is on amd64 where the SIZE is larger and everything else was > the same as on i386. Now amd64 shows the large preallocation too. > > There seems to be another bug for the especially small LIMIT of 16 to > turn into a preallocation of 2535 and not cause immediate reduction to > the limit. > > I happen to have kernels from 24 and 25 Jan handy. The first one is > amd64 r343346M built on Jan 23, and it doesn't do the large > preallocation. The second one is i386 r343388:343418M built on Jan > 25, and it does the large preallocation. Both call uma_prealloc() to > ask for nswbuf_max = 0x9e9 buffers, but the old version only allocates > 4 buffers while later version allocate 0x9e9 buffers. > > The only relevant commit between the good and bad versions seems to be > r343453. This fixes uma_prealloc() to actually work. But it is a feature > for it to not work when its caller asks for too much. I guess you meant r343353. In any case, the pbuf keg is _NOFREE, so even without preallocation the large pbuf zone limits may become problematic if there are bursts of allocation requests. > 0x9e9 is the sum of the LIMITs of all pbuf pools. The main bug in > r343030 is that it expands nswbuf, which is supposed to give the > combined limit, from its normal value of 256 to 0x9e9. (r343030 > actually used nswbuf before it was properly initialized, so used its > maximum value of 256 even on small systems with nswbuf = 16. Only > this has been fixed.) > > On i386, nbuf is excessively limited so as to give a maxbufspace of > about 100MB so as to fit in 1GB of kva even with infinite RAM and > -current's actual 4GB of kva. nbuf is correctly limited to give a > much smaller maxbufspace when RAM is small (kva scaling for this is > not done so well). nswbuf is restricted if nbuf is restricted, but > not enough (except in my version). It is normally 256, so the pbuf > allocation used to be 32MB, and this is already a bit large compared > with 100MB for maxbufspace. Expanding pbufs by a factor of 0x9e9/0x100 > gives the silly combination of 100MB for maxbufspace and 317MB for > pbufs. > > If kva is only 512MB instead of 1GB, then maxbufspace should be only > 50MB and nswbuf should be smaller too. Similarly for PAE on i386 back > when it was configured with 1GB kva by default. Only about 512MB are > left after allocating space for page table metadata. I have fixes > that scale most of this better. Large subsystems starting with kmem > get a hard-coded fraction of the usable kva. E.g., kmem gets about > 60% of usable kva instead of about 40% of nominal kva. Most other > large subsystems including the buffer cache get about 1/8 of the > remaining 40% of usable kva. Scaling for other subsystems is mostly > worse than for kmem. pbufs are part of the buffer cache allocation. > The expansion factor of 0x9e9/0x100 breaks this. > > I don't understand how pbuf_preallocate() allocates
svn commit: r344129 - head
Author: imp Date: Thu Feb 14 17:04:04 2019 New Revision: 344129 URL: https://svnweb.freebsd.org/changeset/base/344129 Log: Fix small typo. Differential Review: https://reviews.freebsd.org/D19193 Modified: head/UPDATING Modified: head/UPDATING == --- head/UPDATING Thu Feb 14 15:45:53 2019(r344128) +++ head/UPDATING Thu Feb 14 17:04:04 2019(r344129) @@ -237,7 +237,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: 20180719: ARM64 now have efifb support, if you want to have serial console on your arm64 board when an screen is connected and the bootloader - setup a frambuffer for us to use, just add : + setup a framebuffer for us to use, just add : boot_serial=YES boot_multicons=YES in /boot/loader.conf ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344132 - head/sys/dev/ixl
Author: erj
Date: Thu Feb 14 18:02:37 2019
New Revision: 344132
URL: https://svnweb.freebsd.org/changeset/base/344132
Log:
ixl: Fix panic caused by bug exposed by r344062
Don't use a struct if_irq for IFLIB_INTR_IOV type interrupts since that
results
in get_core_offset() being called on them, and get_core_offset() doesn't
handle IFLIB_INTR_IOV type interrupts, which results in an assert() being
triggered
in iflib_irq_set_affinity().
PR: 235730
Reported by: Jeffrey Pieper
MFC after:1 day
Sponsored by: Intel Corporation
Modified:
head/sys/dev/ixl/if_ixl.c
head/sys/dev/ixl/ixl_pf.h
Modified: head/sys/dev/ixl/if_ixl.c
==
--- head/sys/dev/ixl/if_ixl.c Thu Feb 14 18:01:06 2019(r344131)
+++ head/sys/dev/ixl/if_ixl.c Thu Feb 14 18:02:37 2019(r344132)
@@ -932,7 +932,7 @@ ixl_if_msix_intr_assign(if_ctx_t ctx, int msix)
return (err);
}
/* Create soft IRQ for handling VFLRs */
- iflib_softirq_alloc_generic(ctx, &pf->iov_irq, IFLIB_INTR_IOV, pf, 0,
"iov");
+ iflib_softirq_alloc_generic(ctx, NULL, IFLIB_INTR_IOV, pf, 0, "iov");
/* Now set up the stations */
for (i = 0, vector = 1; i < vsi->shared->isc_nrxqsets; i++, vector++,
rx_que++) {
Modified: head/sys/dev/ixl/ixl_pf.h
==
--- head/sys/dev/ixl/ixl_pf.h Thu Feb 14 18:01:06 2019(r344131)
+++ head/sys/dev/ixl/ixl_pf.h Thu Feb 14 18:02:37 2019(r344132)
@@ -138,7 +138,6 @@ struct ixl_pf {
struct ixl_vf *vfs;
int num_vfs;
uint16_tveb_seid;
- struct if_irq iov_irq;
};
/*
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344132 - head/sys/dev/ixl
> Author: erj
> Date: Thu Feb 14 18:02:37 2019
> New Revision: 344132
> URL: https://svnweb.freebsd.org/changeset/base/344132
>
> Log:
> ixl: Fix panic caused by bug exposed by r344062
>
> Don't use a struct if_irq for IFLIB_INTR_IOV type interrupts since that
> results
> in get_core_offset() being called on them, and get_core_offset() doesn't
> handle IFLIB_INTR_IOV type interrupts, which results in an assert() being
> triggered
> in iflib_irq_set_affinity().
>
> PR: 235730
> Reported by:Jeffrey Pieper
> MFC after: 1 day
Normally you would request an RE@ approval for a fast track to stable,
consider this message such an approval.
> Sponsored by: Intel Corporation
>
> Modified:
> head/sys/dev/ixl/if_ixl.c
> head/sys/dev/ixl/ixl_pf.h
>
> Modified: head/sys/dev/ixl/if_ixl.c
> ==
> --- head/sys/dev/ixl/if_ixl.c Thu Feb 14 18:01:06 2019(r344131)
> +++ head/sys/dev/ixl/if_ixl.c Thu Feb 14 18:02:37 2019(r344132)
> @@ -932,7 +932,7 @@ ixl_if_msix_intr_assign(if_ctx_t ctx, int msix)
> return (err);
> }
> /* Create soft IRQ for handling VFLRs */
> - iflib_softirq_alloc_generic(ctx, &pf->iov_irq, IFLIB_INTR_IOV, pf, 0,
> "iov");
> + iflib_softirq_alloc_generic(ctx, NULL, IFLIB_INTR_IOV, pf, 0, "iov");
>
> /* Now set up the stations */
> for (i = 0, vector = 1; i < vsi->shared->isc_nrxqsets; i++, vector++,
> rx_que++) {
>
> Modified: head/sys/dev/ixl/ixl_pf.h
> ==
> --- head/sys/dev/ixl/ixl_pf.h Thu Feb 14 18:01:06 2019(r344131)
> +++ head/sys/dev/ixl/ixl_pf.h Thu Feb 14 18:02:37 2019(r344132)
> @@ -138,7 +138,6 @@ struct ixl_pf {
> struct ixl_vf *vfs;
> int num_vfs;
> uint16_tveb_seid;
> - struct if_irq iov_irq;
> };
>
> /*
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344129 - head
> Author: imp > Date: Thu Feb 14 17:04:04 2019 > New Revision: 344129 > URL: https://svnweb.freebsd.org/changeset/base/344129 > > Log: > Fix small typo. A small request, when we fix a typo could we do: fix typo: frambuffer -> framebuffer Thanks, Rod > > Differential Review: https://reviews.freebsd.org/D19193 You sited a differential, but not give any attribution to the external source :-( > Modified: > head/UPDATING > > Modified: head/UPDATING > == > --- head/UPDATING Thu Feb 14 15:45:53 2019(r344128) > +++ head/UPDATING Thu Feb 14 17:04:04 2019(r344129) > @@ -237,7 +237,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: > 20180719: > ARM64 now have efifb support, if you want to have serial console > on your arm64 board when an screen is connected and the bootloader > - setup a frambuffer for us to use, just add : > + setup a framebuffer for us to use, just add : > boot_serial=YES > boot_multicons=YES > in /boot/loader.conf -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344129 - head
On Thu, Feb 14, 2019 at 11:29 AM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > Author: imp > > Date: Thu Feb 14 17:04:04 2019 > > New Revision: 344129 > > URL: https://svnweb.freebsd.org/changeset/base/344129 > > > > Log: > > Fix small typo. > > A small request, when we fix a typo could we > do: > fix typo: frambuffer -> framebuffer > No. Diff tells you that. > Thanks, > Rod > > > > Differential Review: https://reviews.freebsd.org/D19193 > > You sited a differential, but not give any attribution > to the external source :-( > The differential review has that information. Warner > > Modified: > > head/UPDATING > > > > Modified: head/UPDATING > > > == > > --- head/UPDATING Thu Feb 14 15:45:53 2019(r344128) > > +++ head/UPDATING Thu Feb 14 17:04:04 2019(r344129) > > @@ -237,7 +237,7 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: > > 20180719: > > ARM64 now have efifb support, if you want to have serial console > > on your arm64 board when an screen is connected and the bootloader > > - setup a frambuffer for us to use, just add : > > + setup a framebuffer for us to use, just add : > > boot_serial=YES > > boot_multicons=YES > > in /boot/loader.conf > > -- > Rod Grimes > rgri...@freebsd.org > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344133 - head/sys/kern
Author: bde
Date: Thu Feb 14 19:07:08 2019
New Revision: 344133
URL: https://svnweb.freebsd.org/changeset/base/344133
Log:
Finish the fix for overflow in calcru1().
The previous fix was unnecessarily very slow up to 105 hours where the
simple formula used previously worked, and unnecessarily slow by a factor
of about 5/3 up to 388 days, and didn't work above 388 days. 388 days is
not a long time, since it is a reasonable uptime, and for processes the
times being calculated are aggregated over all threads, so with N CPUs
running the same thread a runtime of 388 days is reachable after only
388 / N physical days.
The PRs document overflow at 388 days, but don't try to fix it.
Use the simple formula up to 76 hours. Then use a complicated general
method that reduces to the simple formula up to a bit less than 105
hours, then reduces to the previous method without its extra work up
to almost 388 days, then does more complicated reductions, usually
many bits at a time so that this is not slow. This works up to half
of maximum representable time (292271 years), with accumulated rounding
errors of at most 32 usec.
amd64 can do all this with no avoidable rounding errors in an inline
asm with 2 instructions, but this is too special to use. __uint128_t
can do the same with 100's of instructions on 64-bit arches. Long
doubles with at least 64 bits of precision are the easiest method to
use on i386 userland, but are hard to use in the kernel.
PR: 76972 and duplicates
Reviewed by: kib
Modified:
head/sys/kern/kern_resource.c
Modified: head/sys/kern/kern_resource.c
==
--- head/sys/kern/kern_resource.c Thu Feb 14 18:02:37 2019
(r344132)
+++ head/sys/kern/kern_resource.c Thu Feb 14 19:07:08 2019
(r344133)
@@ -863,13 +863,88 @@ rufetchtd(struct thread *td, struct rusage *ru)
calcru1(p, &td->td_rux, &ru->ru_utime, &ru->ru_stime);
}
+/* XXX: the MI version is too slow to use: */
+#ifndef __HAVE_INLINE_FLSLL
+#defineflsll(x)(fls((x) >> 32) != 0 ? fls((x) >> 32) + 32 :
fls(x))
+#endif
+
static uint64_t
mul64_by_fraction(uint64_t a, uint64_t b, uint64_t c)
{
+ uint64_t acc, bh, bl;
+ int i, s, sa, sb;
+
/*
-* Compute floor(a * (b / c)) without overflowing, (b / c) <= 1.0.
+* Calculate (a * b) / c accurately enough without overflowing. c
+* must be nonzero, and its top bit must be 0. a or b must be
+* <= c, and the implementation is tuned for b <= c.
+*
+* The comments about times are for use in calcru1() with units of
+* microseconds for 'a' and stathz ticks at 128 Hz for b and c.
+*
+* Let n be the number of top zero bits in c. Each iteration
+* either returns, or reduces b by right shifting it by at least n.
+* The number of iterations is at most 1 + 64 / n, and the error is
+* at most the number of iterations.
+*
+* It is very unusual to need even 2 iterations. Previous
+* implementations overflowed essentially by returning early in the
+* first iteration, with n = 38 giving overflow at 105+ hours and
+* n = 32 giving overlow at at 388+ days despite a more careful
+* calculation. 388 days is a reasonable uptime, and the calculation
+* needs to work for the uptime times the number of CPUs since 'a'
+* is per-process.
*/
- return ((a / c) * b + (a % c) * (b / c) + (a % c) * (b % c) / c);
+ if (a >= (uint64_t)1 << 63)
+ return (0); /* Unsupported arg -- can't happen. */
+ acc = 0;
+ for (i = 0; i < 128; i++) {
+ sa = flsll(a);
+ sb = flsll(b);
+ if (sa + sb <= 64)
+ /* Up to 105 hours on first iteration. */
+ return (acc + (a * b) / c);
+ if (a >= c) {
+ /*
+* This reduction is based on a = q * c + r, with the
+* remainder r < c. 'a' may be large to start, and
+* moving bits from b into 'a' at the end of the loop
+* sets the top bit of 'a', so the reduction makes
+* significant progress.
+*/
+ acc += (a / c) * b;
+ a %= c;
+ sa = flsll(a);
+ if (sa + sb <= 64)
+ /* Up to 388 days on first iteration. */
+ return (acc + (a * b) / c);
+ }
+
+ /*
+* This step writes a * b as a * ((bh << s) + bl) =
+* a * (bh << s) + a * bl = (a << s) * bh + a * bl. The 2
+* additive terms are handled separately. Sp
Re: svn commit: r344129 - head
On Thu, Feb 14, 2019 at 12:00:22PM -0700, Warner Losh wrote: > On Thu, Feb 14, 2019 at 11:29 AM Rodney W. Grimes < > > > Differential Review: https://reviews.freebsd.org/D19193 > > > > You sited a differential, but not give any attribution > > to the external source :-( > > > > The differential review has that information. External contributors should be recognized by having their names appear in the commit logs. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344132 - head/sys/dev/ixl
On 2/14/19 10:22 AM, Rodney W. Grimes wrote: >> Author: erj >> Date: Thu Feb 14 18:02:37 2019 >> New Revision: 344132 >> URL: https://svnweb.freebsd.org/changeset/base/344132 >> >> Log: >> ixl: Fix panic caused by bug exposed by r344062 >> >> Don't use a struct if_irq for IFLIB_INTR_IOV type interrupts since that >> results >> in get_core_offset() being called on them, and get_core_offset() doesn't >> handle IFLIB_INTR_IOV type interrupts, which results in an assert() being >> triggered >> in iflib_irq_set_affinity(). >> >> PR:235730 >> Reported by: Jeffrey Pieper >> MFC after: 1 day > > Normally you would request an RE@ approval for a fast track to stable, > consider this message such an approval. That does not match our historical practice over the past 20 years. If we want to change that practice, that's a topic we can debate, but re@ has only required oversight on MFC's during slushes/freezes with the additional caveat of perhaps watching out for ABI breakage at any time (and requiring approvals for a known ABI breakage on a branch). -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344129 - head
> On Thu, Feb 14, 2019 at 12:00:22PM -0700, Warner Losh wrote: > > On Thu, Feb 14, 2019 at 11:29 AM Rodney W. Grimes < > > > > Differential Review: https://reviews.freebsd.org/D19193 > > > > > > You sited a differential, but not give any attribution > > > to the external source :-( > > > > > > > The differential review has that information. > > External contributors should be recognized by having their names appear > in the commit logs. We even bother to put a special line in the commit template for this. Further it has been standard operating procedure for at least as long as I have been back that submitters are infact recognized in commit messages. You have, again, summarily dismissed valid feedback. -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344129 - head
On Thu, 14 Feb 2019 at 12:42, Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Thu, Feb 14, 2019 at 12:00:22PM -0700, Warner Losh wrote:
> > > On Thu, Feb 14, 2019 at 11:29 AM Rodney W. Grimes <
> > > > > Differential Review: https://reviews.freebsd.org/D19193
> > > >
> > > > You sited a differential, but not give any attribution
> > > > to the external source :-(
> > > >
> > >
> > > The differential review has that information.
> >
> > External contributors should be recognized by having their names appear
> > in the commit logs.
>
> We even bother to put a special line in the commit template
> for this. Further it has been standard operating procedure
> for at least as long as I have been back that submitters
> are infact recognized in commit messages.
>
Yeah, Phabricator must not become a second source of truth for who actually
did the work, which we had at least one case of recently. That's no good.
In this case, the difference between a patch and a bug report is
indistinguishable ("word X is misspelt at offset Y in file Z" is probably
not really Phabricator fodder at the scale of a single instance), but it
should plainly either be a Reported byline if not a Submitted one in the
commit message itself.
Juli.
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344129 - head
On Thu, Feb 14, 2019, 1:48 PM Juli Mallett On Thu, 14 Feb 2019 at 12:42, Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On Thu, Feb 14, 2019 at 12:00:22PM -0700, Warner Losh wrote:
>> > > On Thu, Feb 14, 2019 at 11:29 AM Rodney W. Grimes <
>> > > > > Differential Review: https://reviews.freebsd.org/D19193
>> > > >
>> > > > You sited a differential, but not give any attribution
>> > > > to the external source :-(
>> > > >
>> > >
>> > > The differential review has that information.
>> >
>> > External contributors should be recognized by having their names appear
>> > in the commit logs.
>>
>> We even bother to put a special line in the commit template
>> for this. Further it has been standard operating procedure
>> for at least as long as I have been back that submitters
>> are infact recognized in commit messages.
>>
>
> Yeah, Phabricator must not become a second source of truth for who
> actually did the work, which we had at least one case of recently. That's
> no good. In this case, the difference between a patch and a bug report is
> indistinguishable ("word X is misspelt at offset Y in file Z" is probably
> not really Phabricator fodder at the scale of a single instance), but it
> should plainly either be a Reported byline if not a Submitted one in the
> commit message itself.
>
This is the most pointless waste of time of the year. It was a one letter
typo. Yes, maybe I should have included the submitter's name, but I didn't.
It doesn't deserve a long thread and a snarky response. Geeze people, get
some perspective.
Warner
>
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
Hi Justin,
On Wed, Feb 13, 2019 at 07:24:50PM -0600, Justin Hibbits wrote:
J> This seems to break 32-bit platforms, or at least 32-bit book-e
J> powerpc, which has a limited KVA space (~500MB). It preallocates I've
J> seen over 2500 pbufs, at 128kB each, eating up over 300MB KVA,
J> leaving very little left for the rest of runtime.
J>
J> I spent a couple hours earlier today debugging with Mark Johnston, and
J> his consensus is that the vnode_pbuf_zone is too big on 32-bit
J> platforms. Unfortunately I know very little about this area, so can't
J> provide much extra insight, but can readily reproduce the issues I see
J> triggered by this change, so am willing to help where I can.
Ok, let's roll back to old default on 32-bit platforms and somewhat
reduce the default on 64-bits.
Can you please confirm that the patch attached works for you?
--
Gleb Smirnoff
diff --git a/sys/vm/vnode_pager.c b/sys/vm/vnode_pager.c
index 3e71ab4436cc..ded9e65e4e4c 100644
--- a/sys/vm/vnode_pager.c
+++ b/sys/vm/vnode_pager.c
@@ -115,13 +115,23 @@ SYSCTL_PROC(_debug, OID_AUTO, vnode_domainset, CTLTYPE_STRING | CTLFLAG_RW,
&vnode_domainset, 0, sysctl_handle_domainset, "A",
"Default vnode NUMA policy");
+static int nvnpbufs;
+SYSCTL_INT(_vm, OID_AUTO, vnode_pbufs, CTLFLAG_RDTUN | CTLFLAG_NOFETCH,
+&nvnpbufs, 0, "number of physical buffers allocated for vnode pager");
+
static uma_zone_t vnode_pbuf_zone;
static void
vnode_pager_init(void *dummy)
{
- vnode_pbuf_zone = pbuf_zsecond_create("vnpbuf", nswbuf * 8);
+#ifdef __LP64__
+ nvnpbufs = nswbuf * 2;
+#else
+ nvnpbufs = nswbuf / 2;
+#endif
+ TUNABLE_INT_FETCH("vm.vnode_pbufs", &nvnpbufs);
+ vnode_pbuf_zone = pbuf_zsecond_create("vnpbuf", nvnpbufs);
}
SYSINIT(vnode_pager, SI_SUB_CPU, SI_ORDER_ANY, vnode_pager_init, NULL);
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
> On Feb 14, 2019, at 15:34, Gleb Smirnoff wrote: > > Hi Justin, > > On Wed, Feb 13, 2019 at 07:24:50PM -0600, Justin Hibbits wrote: > J> This seems to break 32-bit platforms, or at least 32-bit book-e > J> powerpc, which has a limited KVA space (~500MB). It preallocates I've > J> seen over 2500 pbufs, at 128kB each, eating up over 300MB KVA, > J> leaving very little left for the rest of runtime. > J> > J> I spent a couple hours earlier today debugging with Mark Johnston, and > J> his consensus is that the vnode_pbuf_zone is too big on 32-bit > J> platforms. Unfortunately I know very little about this area, so can't > J> provide much extra insight, but can readily reproduce the issues I see > J> triggered by this change, so am willing to help where I can. > > Ok, let's roll back to old default on 32-bit platforms and somewhat > reduce the default on 64-bits. > > Can you please confirm that the patch attached works for you? Quick question: why was the value reduced by a factor of 4 on 64-bit platforms? Thanks so much! -Enji ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344129 - head
On Thu, Feb 14, 2019, 1:42 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net wrote: > > On Thu, Feb 14, 2019 at 12:00:22PM -0700, Warner Losh wrote: > > > On Thu, Feb 14, 2019 at 11:29 AM Rodney W. Grimes < > > > > > Differential Review: https://reviews.freebsd.org/D19193 > > > > > > > > You sited a differential, but not give any attribution > > > > to the external source :-( > > > > > > > > > > The differential review has that information. > > > > External contributors should be recognized by having their names appear > > in the commit logs. > > We even bother to put a special line in the commit template > for this. Further it has been standard operating procedure > for at least as long as I have been back that submitters > are infact recognized in commit messages. > > You have, again, summarily dismissed valid feedback. > The problem is that was a trivial commit. And you offered not one, but two complaints about adding an 'e' to the updating file. That's what pissed me off. It's advice that might be correct, but was so far over the top, in public, for such a trivial commit. That's why I got mad: it added no value and seemed nit picky and pretty. So I lost it. I shouldn't have, but I did. I'm sorry for my cool. Warner > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344140 - in head/sys: conf modules/crypto opencrypto
Author: sef
Date: Fri Feb 15 03:46:39 2019
New Revision: 344140
URL: https://svnweb.freebsd.org/changeset/base/344140
Log:
Add CBC-MAC authentication.
This adds the CBC-MAC code to the kernel, but does not hook it up to
anything (that comes in the next commit).
https://tools.ietf.org/html/rfc3610 describes the algorithm.
Note that this is a software-only implementation, which means it is
fairly slow.
Sponsored by: iXsystems Inc
Differential Revision: https://reviews.freebsd.org/D18592
Added:
head/sys/opencrypto/cbc_mac.c (contents, props changed)
head/sys/opencrypto/cbc_mac.h (contents, props changed)
head/sys/opencrypto/xform_cbc_mac.c (contents, props changed)
Modified:
head/sys/conf/files
head/sys/modules/crypto/Makefile
head/sys/opencrypto/cryptodev.h
Modified: head/sys/conf/files
==
--- head/sys/conf/files Fri Feb 15 00:29:44 2019(r344139)
+++ head/sys/conf/files Fri Feb 15 03:46:39 2019(r344140)
@@ -4847,6 +4847,8 @@ crypto/libsodium/randombytes.coptional crypto \
compile-with "${NORMAL_C} -I$S/contrib/libsodium/src/libsodium/include
-I$S/crypto/libsodium"
crypto/libsodium/utils.c optional crypto \
compile-with "${NORMAL_C} -I$S/contrib/libsodium/src/libsodium/include
-I$S/crypto/libsodium"
+opencrypto/cbc_mac.c optional crypto
+opencrypto/xform_cbc_mac.c optional crypto
rpc/auth_none.coptional krpc | nfslockd | nfscl | nfsd
rpc/auth_unix.coptional krpc | nfslockd | nfscl | nfsd
rpc/authunix_prot.coptional krpc | nfslockd | nfscl | nfsd
Modified: head/sys/modules/crypto/Makefile
==
--- head/sys/modules/crypto/MakefileFri Feb 15 00:29:44 2019
(r344139)
+++ head/sys/modules/crypto/MakefileFri Feb 15 03:46:39 2019
(r344140)
@@ -68,5 +68,7 @@ CFLAGS.utils.c+= -I${LIBSODIUM_INC}
-I${LIBSODIUM_C
SRCS += opt_param.h cryptodev_if.h bus_if.h device_if.h
SRCS += opt_ddb.h
+SRCS += cbc_mac.c
+SRCS += xform_cbc_mac.c
.include
Added: head/sys/opencrypto/cbc_mac.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/sys/opencrypto/cbc_mac.c Fri Feb 15 03:46:39 2019
(r344140)
@@ -0,0 +1,252 @@
+/*
+ * Copyright (c) 2018-2019 iXsystems Inc. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+__FBSDID("$FreeBSD$);
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Given two CCM_CBC_BLOCK_LEN blocks, xor
+ * them into dst, and then encrypt dst.
+ */
+static void
+xor_and_encrypt(struct aes_cbc_mac_ctx *ctx,
+ const uint8_t *src, uint8_t *dst)
+{
+ const uint64_t *b1;
+ uint64_t *b2;
+ uint64_t temp_block[CCM_CBC_BLOCK_LEN/sizeof(uint64_t)];
+
+ b1 = (const uint64_t*)src;
+ b2 = (uint64_t*)dst;
+
+ for (size_t count = 0;
+count < CCM_CBC_BLOCK_LEN/sizeof(uint64_t);
+count++) {
+ temp_block[count] = b1[count] ^ b2[count];
+ }
+ rijndaelEncrypt(ctx->keysched, ctx->rounds, (void*)temp_block, dst);
+}
+
+void
+AES_CBC_MAC_Init(struct aes_cbc_mac_ctx *ctx)
+{
+ bzero(ctx, sizeof(*ctx));
+}
+
+void
+AES_CBC_MAC_Setkey(struct aes_cbc_mac_ctx *ctx, const uint8_t *key, uint16_t
klen)
+{
+ ctx->rounds = rijndaelKeySetupEnc(ctx->keysched, key, klen * 8);
+}
+
+/*
+ * This is called to set the nonce, aka IV.
+ * Before this call, the authDataLength and crypt
svn commit: r344141 - in head: sys/opencrypto tools/tools/crypto
Author: sef
Date: Fri Feb 15 03:53:03 2019
New Revision: 344141
URL: https://svnweb.freebsd.org/changeset/base/344141
Log:
Add AES-CCM encryption, and plumb into OCF.
This commit essentially has three parts:
* Add the AES-CCM encryption hooks. This is in and of itself fairly small,
as there is only a small difference between CCM and the other ICM-based
algorithms.
* Hook the code into the OpenCrypto framework. This is the bulk of the
changes, as the algorithm type has to be checked for, and the differences
between it and GCM dealt with.
* Update the cryptocheck tool to be aware of it. This is invaluable for
confirming that the code works.
This is a software-only implementation, meaning that the performance is very
low.
Sponsored by: iXsystems Inc.
Differential Revision:https://reviews.freebsd.org/D19090
Modified:
head/sys/opencrypto/cryptodev.c
head/sys/opencrypto/cryptodev.h
head/sys/opencrypto/cryptosoft.c
head/sys/opencrypto/xform_aes_icm.c
head/sys/opencrypto/xform_auth.h
head/sys/opencrypto/xform_enc.h
head/tools/tools/crypto/cryptocheck.c
Modified: head/sys/opencrypto/cryptodev.c
==
--- head/sys/opencrypto/cryptodev.c Fri Feb 15 03:46:39 2019
(r344140)
+++ head/sys/opencrypto/cryptodev.c Fri Feb 15 03:53:03 2019
(r344141)
@@ -444,6 +444,9 @@ cryptof_ioctl(
case CRYPTO_CHACHA20:
txform = &enc_xform_chacha20;
break;
+ case CRYPTO_AES_CCM_16:
+ txform = &enc_xform_ccm;
+ break;
default:
CRYPTDEB("invalid cipher");
@@ -488,6 +491,25 @@ cryptof_ioctl(
thash = &auth_hash_nist_gmac_aes_256;
break;
+ case CRYPTO_AES_CCM_CBC_MAC:
+ switch (sop->keylen) {
+ case 16:
+ thash = &auth_hash_ccm_cbc_mac_128;
+ break;
+ case 24:
+ thash = &auth_hash_ccm_cbc_mac_192;
+ break;
+ case 32:
+ thash = &auth_hash_ccm_cbc_mac_256;
+ break;
+ default:
+ CRYPTDEB("Invalid CBC MAC key size %d",
+ sop->keylen);
+ SDT_PROBE1(opencrypto, dev, ioctl,
+ error, __LINE__);
+ return (EINVAL);
+ }
+ break;
#ifdef notdef
case CRYPTO_MD5:
thash = &auth_hash_md5;
@@ -1003,12 +1025,13 @@ cryptodev_aead(
}
/*
-* For GCM, crd_len covers only the AAD. For other ciphers
+* For GCM/CCM, crd_len covers only the AAD. For other ciphers
* chained with an HMAC, crd_len covers both the AAD and the
* cipher text.
*/
crda->crd_skip = 0;
- if (cse->cipher == CRYPTO_AES_NIST_GCM_16)
+ if (cse->cipher == CRYPTO_AES_NIST_GCM_16 ||
+ cse->cipher == CRYPTO_AES_CCM_16)
crda->crd_len = caead->aadlen;
else
crda->crd_len = caead->aadlen + caead->len;
Modified: head/sys/opencrypto/cryptodev.h
==
--- head/sys/opencrypto/cryptodev.h Fri Feb 15 03:46:39 2019
(r344140)
+++ head/sys/opencrypto/cryptodev.h Fri Feb 15 03:53:03 2019
(r344141)
@@ -133,6 +133,7 @@
#defineARC4_IV_LEN 1
#defineAES_GCM_IV_LEN 12
+#defineAES_CCM_IV_LEN 12
#defineAES_XTS_IV_LEN 8
#defineAES_XTS_ALPHA 0x87/* GF(2^128) generator
polynomial */
@@ -204,7 +205,8 @@
#defineCRYPTO_SHA2_512 37
#defineCRYPTO_POLY1305 38
#defineCRYPTO_AES_CCM_CBC_MAC 39 /* auth side */
-#defineCRYPTO_ALGORITHM_MAX39 /* Keep updated - see below */
+#defineCRYPTO_AES_CCM_16 40 /* cipher side */
+#defineCRYPTO_ALGORITHM_MAX40 /* Keep updated - see below */
#defineCRYPTO_ALGO_VALID(x)((x) >= CRYPTO_ALGORITHM_MIN && \
(x) <= CRYPTO_ALGORITHM_MAX)
Modified: head/sys/opencrypto/cryptosoft.c
==
--- head/sys/opencrypto/cryptosoft.cFri Feb 15 03:46:39 2019
(r344140)
+++ head/sys/opencrypto/cryptosoft.cFri Feb 15 03:53:03 2019
(r344141)
@@ -62,6 +62,9 @@ __FBSDID("$FreeBSD$");
#include
#include "cryptodev_if.h"
+_Static_assert(AES_CCM_IV_LEN ==
svn commit: r344142 - head/sys/opencrypto
Author: sef
Date: Fri Feb 15 04:01:59 2019
New Revision: 344142
URL: https://svnweb.freebsd.org/changeset/base/344142
Log:
Pasting in a source control line missed the last quote. Fixed.
Modified:
head/sys/opencrypto/cbc_mac.c
Modified: head/sys/opencrypto/cbc_mac.c
==
--- head/sys/opencrypto/cbc_mac.c Fri Feb 15 03:53:03 2019
(r344141)
+++ head/sys/opencrypto/cbc_mac.c Fri Feb 15 04:01:59 2019
(r344142)
@@ -23,7 +23,7 @@
*/
#include
-__FBSDID("$FreeBSD$);
+__FBSDID("$FreeBSD$");
#include
#include
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344143 - head/sys/opencrypto
Author: sef
Date: Fri Feb 15 04:15:43 2019
New Revision: 344143
URL: https://svnweb.freebsd.org/changeset/base/344143
Log:
Fix another issue from r344141, having to do with size of a shift amount.
This did not show up in my testing.
Differential Revision:https://reviews.freebsd.org/D18592
Modified:
head/sys/opencrypto/cbc_mac.c
Modified: head/sys/opencrypto/cbc_mac.c
==
--- head/sys/opencrypto/cbc_mac.c Fri Feb 15 04:01:59 2019
(r344142)
+++ head/sys/opencrypto/cbc_mac.c Fri Feb 15 04:15:43 2019
(r344143)
@@ -128,7 +128,7 @@ AES_CBC_MAC_Reinit(struct aes_cbc_mac_ctx *ctx, const
uint16_t sizeVal = htobe16(ctx->authDataLength);
bcopy(&sizeVal, ctx->staging_block, sizeof(sizeVal));
ctx->blockIndex = sizeof(sizeVal);
- } else if (ctx->authDataLength < (1UL<<32)) {
+ } else if (ctx->authDataLength < (1ULL<<32)) {
uint32_t sizeVal = htobe32(ctx->authDataLength);
ctx->staging_block[0] = 0xff;
ctx->staging_block[1] = 0xfe;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
On Thu, 14 Feb 2019, Gleb Smirnoff wrote: On Wed, Feb 13, 2019 at 07:24:50PM -0600, Justin Hibbits wrote: J> This seems to break 32-bit platforms, or at least 32-bit book-e J> powerpc, which has a limited KVA space (~500MB). It preallocates I've J> seen over 2500 pbufs, at 128kB each, eating up over 300MB KVA, J> leaving very little left for the rest of runtime. J> J> I spent a couple hours earlier today debugging with Mark Johnston, and J> his consensus is that the vnode_pbuf_zone is too big on 32-bit J> platforms. Unfortunately I know very little about this area, so can't J> provide much extra insight, but can readily reproduce the issues I see J> triggered by this change, so am willing to help where I can. Ok, let's roll back to old default on 32-bit platforms and somewhat reduce the default on 64-bits. This reduces the largest allocation by a factor of 16 on 32-bit arches, (back to where it was), but it leves the other allocations unchanged, so the total allocation is still almost 5 times larger than before (down from 20 times larger). E.g., with the usual limit of 256 on nswbuf, the total allocation was 32MB with overcommit by a factor of about 5/2 on all systems, but it is now almost 80MB with no overcommit on 32-bit systems. Approximately 0MB of the extras are available on systems with 1GB kva, and less on systems with 512MB kva. Can you please confirm that the patch attached works for you? I don't have any systems affected by the bug, except when I boot with small hw.physmem or large kmem to test things. hw.physmem=72m leaves about 2MB afailable to map into buffers, and doesn't properly reduce nswbuf, so almost 80MB of kva is still used for pbufs. Allocating these must fail due to the RAM shortage. The old value of 32MB gives much the same failures (in practice, a larger operation like fork or exec tends to fail first). Limiting available kva is more interesting, and I haven't tested reducing it intentionally, except once I expanded kmem a lot to put a maximal md malloc()-backed disk in it). Expanding kmem steals from residual kva, and residual kva is not properly scaled except in my version. Large allocations then to cause panics at boot time, except for ones that crash because they don't check for errors. Here is debugging output for large allocations (1MB or more) at boot time on i386: XX pae_mode=0 with ~2.7 GB mapped RAM: XX kva_alloc: large allocation: 7490 pages: 0x580[0x1d42000] vm radix XX kva_alloc: large allocation: 6164 pages: 0x840[0x1814000] pmap init XX kva_alloc: large allocation: 28876 pages: 0xa00[0x70cc000] buf XX kmem_suballoc: large allocation: 1364 pages: 0x1140[0x554000] exec XX kmem_suballoc: large allocation: 10986 pages: 0x11954000[0x2aea000] pipe XX kva_alloc: large allocation: 6656 pages: 0x1480[0x1a0] sfbuf It went far above the old size of 1GB to nearly 1.5GB, but there is plenty to spare out of 4GB. Versions that fitted in 1GB started these allocations about 256MB lower and were otherwise similar. XX pae_mode=1 with 16 GB mapped RAM: XX kva_alloc: large allocation: 43832 pages: 0x14e0[0xab38000] vm radix XX kva_alloc: large allocation: 15668 pages: 0x2000[0x3d34000] pmap init XX kva_alloc: large allocation: 28876 pages: 0x23e0[0x70cc000] buf XX kmem_suballoc: large allocation: 1364 pages: 0x2b00[0x554000] exec XX kmem_suballoc: large allocation: 16320 pages: 0x2b554000[0x3fc] pipe XX kva_alloc: large allocation: 6656 pages: 0x2f60[0x1a0] sfbuf Only the vm radix and pmap init allocations are different, and they start much higher. The allocations now go over 3GB without any useful expansion except for the page tables. PAE was didn't work with 16 GB RAM and 1 GB kva, except in my version. PAE needed to be configured with 2 GB of kva to work with 16 GB RAM, but that was not the default or clearly documented. XX old PAE fixed fit work with 16GB RAM in 1GB KVA: XX kva_alloc: large allocation: 15691 pages: 0xd2c0[0x3d4b000] pmap init XX kva_alloc: large allocation: 43917 pages: 0xd6a0[0xab8d000] vm radix XX kva_alloc: large allocation: 27300 pages: 0xe160[0x6aa4000] buf XX kmem_suballoc: large allocation: 1364 pages: 0xe820[0x554000] exec XX kmem_suballoc: large allocation: 2291 pages: 0xe8754000[0x8f3000] pipe XX kva_alloc: large allocation: 6336 pages: 0xe920[0x18c]sfbuf PAE uses much more kva (almost 256MB extra) before the pmap and radix initializations here too. This is page table metadata before kva allocations are available. The fixes start by keeping track of this amout. It is about 1/16 of the address space for PAE in 1GB, so all later scaling was off by a factor of 16/15 (too high), and since there was less than 1/16 of 1GB to spare, PAE didn't fit. Only 'pipe' is reduced significantly to fit. swzone is reduced to 1 page in all cases, so it doesn't show here. It is about the same as sfbuf IIRC. The fix
Re: svn commit: r344118 - head/sys/i386/include
On Thu, Feb 14, 2019 at 01:53:11PM +, Konstantin Belousov wrote:
> New Revision: 344118
> URL: https://svnweb.freebsd.org/changeset/base/344118
>
> Log:
> Provide userspace versions of do_cpuid() and cpuid_count() on i386.
>
> Some older compilers, when generating PIC code, cannot handle inline
> asm that clobbers %ebx (because %ebx is used as the GOT offset
> register). Userspace versions avoid clobbering %ebx by saving it to
> stack before executing the CPUID instruction.
>
> ...
> +static __inline void
> +do_cpuid(u_int ax, u_int *p)
> +{
> + __asm __volatile(
> + "pushl\t%%ebx\n\t"
> + "cpuid\n\t"
> + "movl\t%%ebx,%1\n\t"
> + "popl\t%%ebx"
Is there a reason to prefer pushl+movl+popl instead of movl+xchgl?
"movl %%ebx, %1\n\t"
"cpuid\n\t"
"xchgl %%ebx, %1"
./danfe
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r343030 - in head/sys: cam conf dev/md dev/nvme fs/fuse fs/nfsclient fs/smbfs kern sys ufs/ffs vm
On Thu, 14 Feb 2019, Mark Johnston wrote: On Thu, Feb 14, 2019 at 06:56:42PM +1100, Bruce Evans wrote: * ... The only relevant commit between the good and bad versions seems to be r343453. This fixes uma_prealloc() to actually work. But it is a feature for it to not work when its caller asks for too much. I guess you meant r343353. In any case, the pbuf keg is _NOFREE, so even without preallocation the large pbuf zone limits may become problematic if there are bursts of allocation requests. Oops. * ... I don't understand how pbuf_preallocate() allocates for the other pbuf pools. When I debugged this for clpbufs, the preallocation was not used. pbuf types other than clpbufs seem to be unused in my configurations. I thought that pbufs were used during initialization, since they end up with a nonzero FREE count, but their only use seems to be to preallocate them. All of the pbuf zones share a common slab allocator. The zones have individual limits but can tap in to the shared preallocation. It seems to be working as intended now (except the allocation count is 3 higher than expected): XX ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP XX XX swrbuf: 336,128, 0, 0, 0, 0, 0 XX swwbuf: 336, 64, 0, 0, 0, 0, 0 XX nfspbuf:336,128, 0, 0, 0, 0, 0 XX mdpbuf: 336, 25, 0, 0, 0, 0, 0 XX clpbuf: 336,128, 0, 35,2918, 0, 0 XX vnpbuf: 336, 2048, 0, 0, 0, 0, 0 XX pbuf: 336, 16, 0,2505, 0, 0, 0 pbuf should har 2537 preallocated and FREE initially, but seems to actually have 2540. pbufs were only used for clustering, and 35 of them were moved from pbuf to clpbuf. In the buggy version, the preallocations stopped after 4. Then clustering presumably moved these 4 to clpbuf. After that, clustering presumably used non-preallocated buffers until it reached its limit, and then recycled its own buffers. What should happen to recover the old overcommit behaviour with better debugging is 256 preallocated buffers (a few more for large systems) in pbuf and moving these to other pools, but never allocating from other pools (keep buffers in other pools only as an optimization and release them to the main pool under pressure). Also allow dynamic tuning of the pool[s] size[s]. The vnode cache does essentially this by using 1 overcommitted pool with unlimited size in uma and external management of the size. The separate pools correspond to separate file systems. These are too hard to manage, so the vnode cache throws everything into the main pool and depends on locality for the overcommit to not be too large. Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
