Re: Deprecating base system ftpd
On 4/10/21 2:58 AM, Scott Bennett via freebsd-stable wrote: [...]I would like something far smaller, namely, a choice of schedulers during/just after installation of a -RELEASE without having to a) download the entire source tree, b) make buildworld, and c) make buildkernel. [...] +1 many times over! I've been hoping someone would implement the schedulers as linkable kernel modules. Surely such a thing is theoretically possible? Maybe there would have to be a dummy scheduler module capable of only single-CPU single-threaded execution to get the kernel to the point where the user-specified real scheduler could be loaded for further operations. This is based, of course, on my complete lack of knowledge about whether the scheduler interface is even compatible with the linkable kernel module interface, etc., etc. But it sure would be nice. -- George OpenPGP_signature Description: OpenPGP digital signature
13.0: partiton names changed
I've just updated an old machine from 12.2 to 13.0 (ea31abc261ffc01b6ff5671bffb15cf910a07f4b) Attaching the /home EBR partition gave me this puzzling error: # geli attach ada0s5 Enter passphrase: geli: Provider not found: "ada0s5" geli: There was an error with at least one provider. Further investigation showed that there is a symlink from /dev/ada0s5 to ada0s4+0001 but geom doesn't recognize ada0s5 anymore. Didn't find anything about it in the release notes: https://www.freebsd.org/releases/13.0R/relnotes/ I guess EBR is no longer in wide use, but this is an old installation, as already mentioned. gpart list in 12.2: Geom name: ada0s4 modified: false state: OK fwheads: 16 fwsectors: 63 last: 473451614 first: 0 entries: 7515105 scheme: EBR Providers: 1. Name: ada0s5 Mediasize: 41948895744 (39G) ... 13.0: Geom name: ada0s4 modified: false state: OK fwheads: 16 fwsectors: 63 last: 473451614 first: 0 entries: 7515105 scheme: EBR Providers: 1. Name: ada0s4+0001 Mediasize: 41948895744 (39G) ... ___ 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: stable/13, vm page counts do not add up
> -Original Message- > From: owner-freebsd-curr...@freebsd.org curr...@freebsd.org> On Behalf Of Mark Johnston > Sent: Wednesday, April 7, 2021 10:57 PM > To: Andriy Gapon > Cc: freebsd-stable List ; FreeBSD Current > > Subject: Re: stable/13, vm page counts do not add up > > On Wed, Apr 07, 2021 at 11:22:41PM +0300, Andriy Gapon wrote: > > On 07/04/2021 22:54, Mark Johnston wrote: > > > On Wed, Apr 07, 2021 at 10:42:57PM +0300, Andriy Gapon wrote: > > >> > > >> I regularly see that the top's memory line does not add up (and by a > > >> lot). > > >> That can be seen with vm.stats as well. > > >> > > >> For example: > > >> $ sysctl vm.stats | fgrep count > > >> vm.stats.vm.v_cache_count: 0 > > >> vm.stats.vm.v_user_wire_count: 3231 > > >> vm.stats.vm.v_laundry_count: 262058 > > >> vm.stats.vm.v_inactive_count: 3054178 > > >> vm.stats.vm.v_active_count: 621131 > > >> vm.stats.vm.v_wire_count: 1871176 > > >> vm.stats.vm.v_free_count: 18 > > >> vm.stats.vm.v_page_count: 8134982 > > >> > > >> $ bc > > > 18 + 1871176 + 621131 + 3054178 + 262058 > > >> 5996320 > > > 8134982 - 5996320 > > >> 2138662 > > >> > > >> As you can see, it's not a small number of pages either. > > >> Approximately 2 million pages, 8 gigabytes or 25% of the whole memory > on this > > >> system. > > >> > > >> This is 47c00a9835926e96, 13.0-STABLE amd64. > > >> I do not think that I saw anything like that when I used (much) older > FreeBSD. > > > > > > One relevant change is that vm_page_wire() no longer removes pages > from > > > LRU queues, so the count of pages in the queues can include wired > pages. > > > If the page daemon runs, it will dequeue any wired pages that are > > > encountered. > > > > Maybe I misunderstand how that works, but I would expect that the sum > of all > > counters could be greater than v_page_count at times. But in my case it's > less. > > I misread, sorry. You're right, what I described would cause double > counting. > > I don't know what might be causing it then. It could be a page leak. > The kernel allocates wired pages without adjusting the v_wire_count > counter in some cases, but the ones I know about happen at boot and > should not account for such a large disparity. I do not see it on a few > systems that I have access to. > > > > This was done to reduce queue lock contention, operations like > > > sendfile() which transiently wire pages would otherwise trigger two > > > queue operations per page. Now that queue operations are batched this > > > might not be as important. > > > > > > We could perhaps add a new flavour of vm_page_wire() which is not lazy > > > and would be suited for e.g., the buffer cache. What is the primary > > > source of wired pages in this case? > > > > It should be ZFS, I guess. > > > > -- > > Andriy Gapon > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscr...@freebsd.org" I see kernel memory disappearing, when enabling ktls: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253281 Last test done with 13.0-RC1. I'm a bit at a loss how to debug this further. Regards Juergen Weiss Juergen Weiss | we...@uni-mainz.de | ___ 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: Deprecating base system ftpd
On Fri, 09 Apr 2021 07:32:12 +0900 aventa...@fastmail.fm wrote: >It makes me think that there should be an offering for two completely >different audiences: >(1) FreeBSD core (a very minimal offering for folks that want to build things, >like a Desktop, etc.) >(2) FreeBSD server (an offering for folks that want a server build) > >Perhaps that idea is just unreasonably crazy as well. > LOL! You have what is called a very big ask. I would like something far smaller, namely, a choice of schedulers during/just after installation of a -RELEASE without having to a) download the entire source tree, b) make buildworld, and c) make buildkernel. The kernel developers in their wisdom--ahem--have burdened all new installations with the abysmal performance of the ULE scheduler. The installation images for -STABLE versions are much the same. The 4BSD scheduler has been far from optimal, and the ULE scheduler looked like a nice idea on paper for newer CPUs, but in fact, the ULE scheduler's performance is awful, even when compared with the 4BSD scheduler, which generally gives acceptable, though not optimal, performance. If the owner of a new installation wants to get passably usable performance from his new system, he must first perform the tasks noted above. The second and third tasks will take *a lot* of extra time because they must be done under the ULE scheduler. Then one must install the new kernel, reboot, do the mergemaster or /etc/update steps, install the new world, more mergemaster or /etc/update, and reboot again. Two ways of allowing a choice of scheduler are 1) to provide two GENERIC kernels, e.g., GENERIC.ULE and GENERIC.4BSD, from which one could choose at boot time, and 2) to compile both schedulers into the GENERIC kernel, which could be selected from by a loader tunable at boot time. The current system is yet another discouragement to upgrading to a new -RELEASE via a new installation. Further, this fix to bad performance by default is not documented anywhere. How is a user who is new to FreeBSD to know about it? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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"
