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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stable/13, vm page counts do not add up
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. > 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: stable/13, vm page counts do not add up
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. 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? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
stable/13, vm page counts do not add up
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. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console getty uses 1.5% of CPU
On Wed, Apr 07, 2021 at 02:33:57PM +, Poul-Henning Kamp wrote: > > T.e. if all system eat 985 ticks of CPU each second and getty eat 15 > > ticks of CPU each second -- top show 1.5% for getty. > > That may be, but getty should not wake up at all in this situation, > it should be sleeping, waiting for modem-control signals. May be some kernel-side ticks counted for getty. You can try check this by dtrace, I mean. Snoop scheduler activation and check process accounting. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console getty uses 1.5% of CPU
Slawa Olhovchenkov writes: > T.e. if all system eat 985 ticks of CPU each second and getty eat 15 > ticks of CPU each second -- top show 1.5% for getty. That may be, but getty should not wake up at all in this situation, it should be sleeping, waiting for modem-control signals. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console getty uses 1.5% of CPU
On Wed, Apr 07, 2021 at 05:22:40AM +, Poul-Henning Kamp wrote: > I have two 12.2-R systems where the serial console is attached to a terminal > server. > > When there are no TCP connections to the terminal server, getty soaks up 1.5% > of the > CPU in the kernel (sleeping in "ttyin"), ktrace shows no system calls. > > When a TCP connection is made to the terminal server, which raises the > modem-handshake > on the DE-9 connector, the CPU usage stops. > > Anybody else seeing something like this ? Problem of comparing low number? Top's "getty 1.5% of the CPU" is not "getty eat 1.5% of the ALL CPU power", this is "getty 1.5% of off all other curerent eats of CPU power". T.e. if all system eat 985 ticks of CPU each second and getty eat 15 ticks of CPU each second -- top show 1.5% for getty. Load is raised to 99_985 ticks for system, getty eat 15 ticks -- top show 0% ( 15/(99985+15) = .015% ). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
