Re: lightly loaded system eats swap space
On 20/06/2018 02:59, Jeremy Chadwick wrote: > In short (and nebulous as hell; sorry, I cannot be more specific given > the nature of the problem): there have been changes about ZFS's memory > allocation/releasing decision-making scheme compared to ZFS on "older" > FreeBSD (i.e. earlier 11.x, and definitely 10.x and 9.x). I would say the issues started with 10.x, I never had memory issues using 9.x with ZFS. I first had all ram marked wired when testing 10.1. > Recommendations like "limit your ARC" are nothing new in FreeBSD, but > are still ridiculous kludges: tech-lists' system clearly has 105GB MRU > (MRU = most recently used) in ARC, meaning there is memory that can be > released back to the rest of the OS for general use (re: memory > contention/pressure situation), but the OS is choosing to use swap > instead, eventually exhausting it. That logic sounds broken, IMO. (And > yes I did notice the size of bhyve process) This review is aiming to fix this - https://reviews.freebsd.org/D7538 I have been running the patch on stable/11 and after eight days uptime I still have zero swap in use, I can't recall a time in the last few years that I have had no swap usage past the first hour or two uptime. As I have commented in that review, the issue I am seeing is that arc_max is not counted when testing max_wired, the two together can add up to more than the physical ram and wiring all physical ram can push ram used by processes out to swap. I know with 8G physical ram having over 7G wired is not recoverable. max_wired seems to default to 30% ram (5G with 16G ram) I have never seen this mentioned in any zfs tuning, it should be subtracted from physical ram when calculating arc_max. arc_max should never be greater than (kmem_size - max_wired - padding) -- FreeBSD - the place to B...Storing Data Shane Ambler ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Does VirtualBox's vboxnetflt(4) work on stable/11 | 11.2?
On Tue, Jun 19, 2018 at 11:30 AM, Harry Schmalzbauer wrote: > Am 16.06.2018 um 21:42 schrieb Harry Schmalzbauer: > … > >> To rule out a known vboxnetflt(4) limitation/failure, I'd like to know if >> somebody successfully uses vboxnetflt(4) from virtualbox-ose-kmod-5.2.12 on >> stable/11|11.2. >> > > Really nobody out there who has VirtualBox sucessfully running under > stable/11 or 11.x with bridged network? > > Anyone who tried, but also observed similar problems like I have on > -current? > > Thanks, > > -harry > I suspect you would have gotten better response if you had asked for someone using a bridged network (as opposed to NATed) on VirtualBox 5.2.12 ib FreeBSD-11. I had to check on just what vboxnetflt was to realize that, yes, I use it and it works fine on my 11-STABLE system system. Worked on 11 from the time 5.12 was placed in ports ubtil now on several different revisions of STABLE. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ATI video problem - extremely slow desktop - 100% cpu load
Hi. FreeBSD 11.1-RELEASE Motherboard:gigabyte GA-78LMT-USB3 R2 Video: Integrated ATI Radeon HD 3000 graphics System runs fine with a simple stand alone window manager such as jwm, openbox, etc. But anytime I run a desktop environment that has a panel and/or desktop icons, the X desktop takes a very long time to start up and runs extremely slow and unresponsive, the pointer jumps instead of moving smoothly, and the main Xorg process runs at 100% load on one core. I have tried several different desktops, such as xfce, enlightenment, lumina, etc. Similar problem on all of them. It appears to be any environment that is using DBUS. That could just be a coincidence. The weird thing is that it does not always do it. Once in a while, when I launch X, it comes up quick and runs fine. Shut down X and re-run it and it's back doing it again. Sometimes it will come up running fine several times in a row. Once it comes up working correctly, it stays working until I restart X. Even after a reboot, it is inconsistent about doing it the first time X is run. I have tried re-installing all the ports from X11 and the desktop environments from FreeBSD 11 release_1, release_2, quarterly, and latest. Same problem with all of them. Does anybody have any idea what could be causing this? I don't know if for sure if this is a FreeBSD or a port problem. There are radeon modules running. # kldstat 51 0x82431000 12b4a0 radeonkms.ko ... 101 0x825b9000 103e radeonkmsfw_RS780_pfp.ko 111 0x825bb000 5b3f radeonkmsfw_RS780_me.ko 121 0x825c1000 1338 radeonkmsfw_R600_rlc.ko X is using the ati driver from the xf86-video-ati-7.9.0_1,1 package. The evidence seems to be pointing toward the xf86-video-ati package being the problem. If I edit /etc/X11/xorg.conf to use the "vesa" driver rather than the "radeon" driver the problem goes away. But, of course, the vesa driver is low resolution and does not re-initialize the console when I exit X. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lightly loaded system eats swap space
19.06.18 20:29, Jeremy Chadwick wrote: (I am not subscribed to -stable, so please CC me, though I doubt I can help in any way/shape/form past this Email) Not the first time this has come up -- and every time it has, all that's heard is crickets in the threads. Recent proof: … I may sound lame but I also faced this issues a few month ago. After a few days of load system was trying to push more and more data into the swap up to the point that active window becomes too small to handle all programs so they should be get back from swap and while they are not running something pinches ARC and ARC claims the memory and so on… I wasn't ever a fan of limiting things. If something requires limits it can be easily exploited. Should I switch from normal limits to other limits when I, say, need to test something on 4 VMs? So while paging through documentation I found a rather old memo in tuning(7) about vm.swap_idle_enabled. I played a little with thresholds but that was only making things worse. I left swap_idle_enable on and let machine live. That was near January I suppose. To my amusement swap problems were gone. This doesn't mean swap wasn't used, instead system survived weeks under irregular load without issues. The only other change that I did was bumping up vfs.zfs.arc_free_target a little bit higher then default to make some space between ARC and VM so they wouldn't clash on memory so often. Since then all of my problems with swap was forgotten. I'm not sure what setting fixed that, neither I'm sure that wasn't some recent patches. I'm running 11-STABLE and rebuilding system at least once per month. Hope that can help someone. WBR. -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
USB trouble on Ryzen 3/AsRock mobo.
Hi. I've recently converted to FreeBSD, fleeing the Windowsification of Ubuntu. I've been having some trouble with the USB system, which seems strange as FreeBSD's USB stack is, according to a friend, rock solid. I'd like to narrow down if this is a hardware (CPU or mobo) or software issue. I'm running a Ryzen 3 1200, plugged into a "Fatal1ty X370 Gaming-ITX/ac" motherboard (chosen because it supports ECC RAM and fits in an ITX case). On a cold boot (ie starting by flipping the physical PSU power switch), BSD boots up nice and quickly, without errors, and then runs for days without a single USB-related error on dmesg. However, any other kind of reboot which doesn't interrupt the electricity supply yields a large number of USB errors (USB_ERR_TIMEOUTs every few seconds or so) and frequent resets of the xhci0 controller. On occasion, I also get problems with my keyboard randomly stopping working (but then, if the USB subsystem is continuously resetting, that's only to be expected). I also seem to get slow USB storage device read throughput (2MB/s from a USB3 SSD), although I can't rule out that being caused by the fuse ext4fs driver. Here's what I see in dmesg when the USB system's in spam mode: xhci0: Resetting controller usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT igb0: link state changed to UP usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT uhid0 on uhub3 uhid0: on usbus1 uhid1 on uhub3 uhid1: on usbus1 ums0 on uhub2 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen0.2: at usbus0 (disconnected) uhub_reattach_port: could not allocate new device uhub1: at usbus0, port 1, addr 1 (disconnected) uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub1: 22 ports with 22 removable, self powered xhci0: Resetting controller - Here's the start of dmesg: - Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.2-PRERELEASE #0 r335198: Fri Jun 15 20:55:02 CEST 2018 phil@bob:/usr/obj/usr/src/sys/BOB amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) VT(efifb): resolution 1024x768 CPU: AMD Ryzen 3 1200 Quad-Core Processor(3094.26-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: (disabled in BIOS) NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16519221248 (15753 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) random: unblocking device. Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x/0x1 (20171214/tbfadt-796) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-55 on motherboard SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 1547130097 Hz quality 1000 random: entropy device external interface kbd0 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x80a3bd40, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.59 Wed May 9 21:54:48 PDT 2018 nexus0 cryptosoft0: on motherboard aesni0: on motherboard acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on
Re: lightly loaded system eats swap space
Hi I had something similar on FreeNAS 11.1 ( based on FreeBSD 11.1). Swap was allocated and never released until it ran out. Some time ago I set the following sysctl: vm.disable_swapspace_pageouts: 1 That completely stopped swap allocation and I have not rebooted since, except for OS patching. >From what I found using google this sysctl may have some nasty side effects >when system runs out of memory, but that has not happened on my system. Paul > On 19 Jun 2018, at 19:57, Cassiano Peixoto wrote: > > Hi, > > I have the very same issue on many servers. Mainly on mail servers running > qmail+spamassassin+clamav. I've tuned some variables on loader.conf: > > vfs.zfs.vdev.cache.size="2G" > vfs.zfs.arc_min="61440" > vfs.zfs.arc_max="491520" > > But after some days, it begins eating swap and the system comes very very > slow then I need to reboot it. > > My system config is: > > FreeBSD 11.1-STABLE #5 r321625M: Thu Sep 21 16:01:56 -03 2017 >r...@mail.com:/usr/obj/usr/src/sys/MAIL amd64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM > 4.0.0) > VT(vga): resolution 640x480 > CPU: Intel(R) Atom(TM) CPU C2518 @ 1.74GHz (1750.04-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x406d8 Family=0x6 Model=0x4d Stepping=8 > > Features=0xbfebfbff > > Features2=0x43d8e3bf > AMD Features=0x28100800 > AMD Features2=0x101 > Structured Extended Features=0x2282 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > real memory = 8589934592 (8192 MB) > avail memory = 8213245952 (7832 MB) > > It's configured with 4GB of swap. Let me know if I can help with any other > information. > > Thanks. > > > On Tue, Jun 19, 2018 at 2:29 PM, Jeremy Chadwick wrote: > >> (I am not subscribed to -stable, so please CC me, though I doubt I can >> help in any way/shape/form past this Email) >> >> Not the first time this has come up -- and every time it has, all that's >> heard is crickets in the threads. Recent proof: >> >> https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088727.html >> https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088728.html >> https://lists.freebsd.org/pipermail/freebsd-stable/2018-June/089094.html >> >> I sent private mail to Peter Jeremy about his issue. I will not >> disclose that Email here. However, I will disclose the commits I >> included in said Email that have touched ZFS ARC-related code: >> >> http://www.freshbsd.org/commit/freebsd/r332785 >> http://www.freshbsd.org/commit/freebsd/r332552 >> http://www.freshbsd.org/commit/freebsd/r332540 (may help give insights) >> http://www.freshbsd.org/commit/freebsd/r330061 >> http://www.freshbsd.org/commit/freebsd/r328235 >> http://www.freshbsd.org/commit/freebsd/r327491 >> http://www.freshbsd.org/commit/freebsd/r326619 >> http://www.freshbsd.org/commit/freebsd/r326427 (quota-related, maybe >> irrelevant) >> http://www.freshbsd.org/commit/freebsd/r323667 >> >> In short (and nebulous as hell; sorry, I cannot be more specific given >> the nature of the problem): there have been changes about ZFS's memory >> allocation/releasing decision-making scheme compared to ZFS on "older" >> FreeBSD (i.e. earlier 11.x, and definitely 10.x and 9.x). >> >> Recommendations like "limit your ARC" are nothing new in FreeBSD, but >> are still ridiculous kludges: tech-lists' system clearly has 105GB MRU >> (MRU = most recently used) in ARC, meaning there is memory that can be >> released back to the rest of the OS for general use (re: memory >> contention/pressure situation), but the OS is choosing to use swap >> instead, eventually exhausting it. That logic sounds broken, IMO. (And >> yes I did notice the size of bhyve process) >> >> ZFS-related kernel folks need to be involved in this conversation. For >> whatever reason, in the past several years, related committers are no >> longer participating in these type of discussions. The opposite was >> true back in the 7.x to 9.x days. The answers have to come from them. >> I don't know, today, a) how they prefer these problems get reported to >> them, or b) what exact information they want that can help narrow it >> down (tech-lists' provided data is, IMO, good and par for the course). >> >> -- >> | Jeremy Chadwick j...@koitsu.org | >> | UNIX Systems Administratorhttp://jdc.koitsu.org/ | >> | Making life hard for others since 1977. PGP 4BD6C0CB | >> >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >
Re: Does VirtualBox's vboxnetflt(4) work on stable/11 | 11.2?
Am 16.06.2018 um 21:42 schrieb Harry Schmalzbauer: … To rule out a known vboxnetflt(4) limitation/failure, I'd like to know if somebody successfully uses vboxnetflt(4) from virtualbox-ose-kmod-5.2.12 on stable/11|11.2. Really nobody out there who has VirtualBox sucessfully running under stable/11 or 11.x with bridged network? Anyone who tried, but also observed similar problems like I have on -current? Thanks, -harry ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lightly loaded system eats swap space
Hi, I have the very same issue on many servers. Mainly on mail servers running qmail+spamassassin+clamav. I've tuned some variables on loader.conf: vfs.zfs.vdev.cache.size="2G" vfs.zfs.arc_min="61440" vfs.zfs.arc_max="491520" But after some days, it begins eating swap and the system comes very very slow then I need to reboot it. My system config is: FreeBSD 11.1-STABLE #5 r321625M: Thu Sep 21 16:01:56 -03 2017 r...@mail.com:/usr/obj/usr/src/sys/MAIL amd64 FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) VT(vga): resolution 640x480 CPU: Intel(R) Atom(TM) CPU C2518 @ 1.74GHz (1750.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406d8 Family=0x6 Model=0x4d Stepping=8 Features=0xbfebfbff Features2=0x43d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8213245952 (7832 MB) It's configured with 4GB of swap. Let me know if I can help with any other information. Thanks. On Tue, Jun 19, 2018 at 2:29 PM, Jeremy Chadwick wrote: > (I am not subscribed to -stable, so please CC me, though I doubt I can > help in any way/shape/form past this Email) > > Not the first time this has come up -- and every time it has, all that's > heard is crickets in the threads. Recent proof: > > https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088727.html > https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088728.html > https://lists.freebsd.org/pipermail/freebsd-stable/2018-June/089094.html > > I sent private mail to Peter Jeremy about his issue. I will not > disclose that Email here. However, I will disclose the commits I > included in said Email that have touched ZFS ARC-related code: > > http://www.freshbsd.org/commit/freebsd/r332785 > http://www.freshbsd.org/commit/freebsd/r332552 > http://www.freshbsd.org/commit/freebsd/r332540 (may help give insights) > http://www.freshbsd.org/commit/freebsd/r330061 > http://www.freshbsd.org/commit/freebsd/r328235 > http://www.freshbsd.org/commit/freebsd/r327491 > http://www.freshbsd.org/commit/freebsd/r326619 > http://www.freshbsd.org/commit/freebsd/r326427 (quota-related, maybe > irrelevant) > http://www.freshbsd.org/commit/freebsd/r323667 > > In short (and nebulous as hell; sorry, I cannot be more specific given > the nature of the problem): there have been changes about ZFS's memory > allocation/releasing decision-making scheme compared to ZFS on "older" > FreeBSD (i.e. earlier 11.x, and definitely 10.x and 9.x). > > Recommendations like "limit your ARC" are nothing new in FreeBSD, but > are still ridiculous kludges: tech-lists' system clearly has 105GB MRU > (MRU = most recently used) in ARC, meaning there is memory that can be > released back to the rest of the OS for general use (re: memory > contention/pressure situation), but the OS is choosing to use swap > instead, eventually exhausting it. That logic sounds broken, IMO. (And > yes I did notice the size of bhyve process) > > ZFS-related kernel folks need to be involved in this conversation. For > whatever reason, in the past several years, related committers are no > longer participating in these type of discussions. The opposite was > true back in the 7.x to 9.x days. The answers have to come from them. > I don't know, today, a) how they prefer these problems get reported to > them, or b) what exact information they want that can help narrow it > down (tech-lists' provided data is, IMO, good and par for the course). > > -- > | Jeremy Chadwick j...@koitsu.org | > | UNIX Systems Administratorhttp://jdc.koitsu.org/ | > | Making life hard for others since 1977. PGP 4BD6C0CB | > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lightly loaded system eats swap space
(I am not subscribed to -stable, so please CC me, though I doubt I can help in any way/shape/form past this Email) Not the first time this has come up -- and every time it has, all that's heard is crickets in the threads. Recent proof: https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088727.html https://lists.freebsd.org/pipermail/freebsd-stable/2018-April/088728.html https://lists.freebsd.org/pipermail/freebsd-stable/2018-June/089094.html I sent private mail to Peter Jeremy about his issue. I will not disclose that Email here. However, I will disclose the commits I included in said Email that have touched ZFS ARC-related code: http://www.freshbsd.org/commit/freebsd/r332785 http://www.freshbsd.org/commit/freebsd/r332552 http://www.freshbsd.org/commit/freebsd/r332540 (may help give insights) http://www.freshbsd.org/commit/freebsd/r330061 http://www.freshbsd.org/commit/freebsd/r328235 http://www.freshbsd.org/commit/freebsd/r327491 http://www.freshbsd.org/commit/freebsd/r326619 http://www.freshbsd.org/commit/freebsd/r326427 (quota-related, maybe irrelevant) http://www.freshbsd.org/commit/freebsd/r323667 In short (and nebulous as hell; sorry, I cannot be more specific given the nature of the problem): there have been changes about ZFS's memory allocation/releasing decision-making scheme compared to ZFS on "older" FreeBSD (i.e. earlier 11.x, and definitely 10.x and 9.x). Recommendations like "limit your ARC" are nothing new in FreeBSD, but are still ridiculous kludges: tech-lists' system clearly has 105GB MRU (MRU = most recently used) in ARC, meaning there is memory that can be released back to the rest of the OS for general use (re: memory contention/pressure situation), but the OS is choosing to use swap instead, eventually exhausting it. That logic sounds broken, IMO. (And yes I did notice the size of bhyve process) ZFS-related kernel folks need to be involved in this conversation. For whatever reason, in the past several years, related committers are no longer participating in these type of discussions. The opposite was true back in the 7.x to 9.x days. The answers have to come from them. I don't know, today, a) how they prefer these problems get reported to them, or b) what exact information they want that can help narrow it down (tech-lists' provided data is, IMO, good and par for the course). -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Pós-Graduação SENAI | FATEC - MBA em Gestão de Projetos
___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lightly loaded system eats swap space
Hi, On Tue, 19 Jun 2018 09:06:42 +0200 Stefan Esser wrote: > Am 19.06.18 um 03:48 schrieb Erich Dollansky: > > A very long time ago - and not on FreeBSD but maybe on a real BSD - > > I worked with a system that swapped pages out just to bring it back > > as one contiguous block. This made a difference those days. I do > > not know if the code made it out of the university I was working > > at. I just imagine now that the code made it out and is still in > > use with the opposite effect. > > If this was on a VAX, then it was due to a short-coming of the > MMU of the VAX, which used one linear array (in system virtual this could have been the case as they have had many DEC systems. > Nothing of the above applies to any other architecture than the > VAX and thus the swap-out of all user processes serves no purpose > on any other system. It was an implementation detail of the VAX > VM code, not a BSD Unix feature. I know how an MMU works, but I also know how caches work. It still could give a tiny advantage if it is in one piece, even if it is not a requirement to function. Any way, I do not work in this area anymore. Erich ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lightly loaded system eats swap space
Am 19.06.18 um 03:48 schrieb Erich Dollansky: > A very long time ago - and not on FreeBSD but maybe on a real BSD - I > worked with a system that swapped pages out just to bring it back as > one contiguous block. This made a difference those days. I do not know > if the code made it out of the university I was working at. I just > imagine now that the code made it out and is still in use with the > opposite effect. If this was on a VAX, then it was due to a short-coming of the MMU of the VAX, which used one linear array (in system virtual memory) to hold physical addresses of user pages of all programs. Each user program had 2 slices in this array (1 growing up, 1 growing down for the stack) and whenever a program allocated a new page, this slice needed to grow. That leads to fragmentation (same a problem as with realloc() for an ever growing array), and when there was no contiguous free space in the array for a grown slice, then all process where swapped out (resulting in this whole page table array being cleared and thus without fragmentation, since swapped-out processes needed no space in this array). This was a solution that worked without the table walk used in todays VM systems. System pages were mapped by a linear page table in physical memory, while user programs used the above described linear page table in system virtual memory. Nothing of the above applies to any other architecture than the VAX and thus the swap-out of all user processes serves no purpose on any other system. It was an implementation detail of the VAX VM code, not a BSD Unix feature. Regards, STefan ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
