On Nov 22, 2025, at 13:55, Mark Millard <[email protected]> wrote: > Konstantin Belousov <kostikbel_at_gmail.com> w rote on > Date: Sat, 22 Nov 2025 20:41:27 UTC : > >> On Sat, Nov 22, 2025 at 10:19:38PM +0200, Konstantin Belousov wrote: >>> Please in addition to the patch, enable debug.vm_check_pg_zero. >> >> And use the following patch (one more hunk for vm_object_page_remove()): >> >> diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c >> index 6b09552c5fee..76808b5ad7f1 100644 >> --- a/sys/vm/vm_map.c >> +++ b/sys/vm/vm_map.c >> @@ -1743,6 +1743,27 @@ vm_map_insert1(vm_map_t map, vm_object_t object, >> vm_ooffset_t offset, >> (vm_size_t)(prev_entry->end - prev_entry->start), >> (vm_size_t)(end - prev_entry->end), cred != NULL && >> (protoeflags & MAP_ENTRY_NEEDS_COPY) == 0)) { >> + vm_object_t obj = prev_entry->object.vm_object; >> + if (obj != NULL) { >> + struct pctrie_iter pages; >> + vm_page_t p; >> + >> + vm_page_iter_init(&pages, obj); >> + p = vm_radix_iter_lookup_ge(&pages, >> + OFF_TO_IDX(prev_entry->offset + >> + prev_entry->end - prev_entry->start)); >> + if (p != NULL) { >> + KASSERT(p->pindex >= OFF_TO_IDX(prev_entry->offset + >> + prev_entry->end - prev_entry->start + >> + end - start), >> + ("FOUND page %p pindex %#jx " >> + "e %#jx %#jx %#jx %#jx", >> + p, p->pindex, (uintmax_t)prev_entry->offset, >> + (uintmax_t)prev_entry->end, >> + (uintmax_t)prev_entry->start, >> + (uintmax_t)(end - start))); >> + } >> + } >> /* >> * We were able to extend the object. Determine if we >> * can extend the previous map entry to include the >> diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c >> index 5b4517d2bf0c..e87047f9a380 100644 >> --- a/sys/vm/vm_object.c >> +++ b/sys/vm/vm_object.c >> @@ -1988,7 +1988,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t >> start, vm_pindex_t end, >> (options & (OBJPR_CLEANONLY | OBJPR_NOTMAPPED)) == OBJPR_NOTMAPPED, >> ("vm_object_page_remove: illegal options for object %p", object)); >> if (object->resident_page_count == 0) >> - return; >> + goto remove_pager; >> vm_object_pip_add(object, 1); >> vm_page_iter_limit_init(&pages, object, end); >> again: >> @@ -2061,6 +2061,7 @@ vm_object_page_remove(vm_object_t object, vm_pindex_t >> start, vm_pindex_t end, >> } >> vm_object_pip_wakeup(object); >> >> +remove_pager: >> vm_pager_freespace(object, start, (end == 0 ? object->size : end) - >> start); >> } >> @@ -2189,13 +2190,19 @@ vm_object_coalesce(vm_object_t prev_object, >> vm_ooffset_t prev_offset, >> next_size >>= PAGE_SHIFT; >> next_pindex = OFF_TO_IDX(prev_offset) + prev_size; >> >> - if (prev_object->ref_count > 1 && >> - prev_object->size != next_pindex && >> + if (prev_object->ref_count > 1 || >> + prev_object->size != next_pindex || >> (prev_object->flags & OBJ_ONEMAPPING) == 0) { >> VM_OBJECT_WUNLOCK(prev_object); >> return (FALSE); >> } >> >> + KASSERT(next_pindex + next_size > prev_object->size, >> + ("vm_object_coalesce: " >> + "obj %p next_pindex %#jx next_size %#jx obj_size %#jx", >> + prev_object, (uintmax_t)next_pindex, (uintmax_t)next_size, >> + (uintmax_t)prev_object->size)); >> + >> /* >> * Account for the charge. >> */ >> @@ -2222,26 +2229,13 @@ vm_object_coalesce(vm_object_t prev_object, >> vm_ooffset_t prev_offset, >> * Remove any pages that may still be in the object from a previous >> * deallocation. >> */ >> - if (next_pindex < prev_object->size) { >> - vm_object_page_remove(prev_object, next_pindex, next_pindex + >> - next_size, 0); >> -#if 0 >> - if (prev_object->cred != NULL) { >> - KASSERT(prev_object->charge >= >> - ptoa(prev_object->size - next_pindex), >> - ("object %p overcharged 1 %jx %jx", prev_object, >> - (uintmax_t)next_pindex, (uintmax_t)next_size)); >> - prev_object->charge -= ptoa(prev_object->size - >> - next_pindex); >> - } >> -#endif >> - } >> + vm_object_page_remove(prev_object, next_pindex, next_pindex + >> + next_size, 0); >> >> /* >> * Extend the object if necessary. >> */ >> - if (next_pindex + next_size > prev_object->size) >> - prev_object->size = next_pindex + next_size; >> + prev_object->size = next_pindex + next_size; >> >> VM_OBJECT_WUNLOCK(prev_object); >> return (TRUE);
[The Email handling did not preserve much of the whitespace in the above diff.] > This completed the lib/clang/libllvm /and lib/clang/libclang/ > build activity from prior partial runs. So I started > buildworld over after doing the "rm -fr". It has completed > past the : > > /usr/obj/usr/src/i386.i386/lib/clang/ > > part of the buildworld and is continuing. > > So far so good. > > > Is 15.0 going to hold off for the final form of this? Get > an EN later? The i386 chroot on amd64 boot-system test finished just fine: -------------------------------------------------------------- >>> World build completed on Sat Nov 22 21:58:09 UTC 2025 >>> World built in 2330 seconds, ncpu: 32, make -j10 -------------------------------------------------------------- As did the armv7 chroot on aarch64 boot-system test: -------------------------------------------------------------- >>> World build completed on Sat Nov 22 17:55:38 PST 2025 >>> World built in 11501 seconds, ncpu: 8, make -j8 -------------------------------------------------------------- (The -jN numbers combined with the RAM+SWAP figures achieved for each made for useful tests of the original problem.) Prior to the changes, each of those had to be restarted a bunch of times to finish the libprivatellvm.so.19 and libprivateclang.so.19 parts of the overall build. The above tests were both made after the new assignment: # sysctl debug.vm_check_pg_zero=1 debug.vm_check_pg_zero: 0 -> 1 that enables some new, expensive INVARIANTS code. Note that the code for testing is not claimed to be the actual fix that will be used. It was for information gathering. As I understand things, the changes involved apply to all supported FreeBSD platforms, not just 32-bit i386 and armv7. It seems jemalloc 5.3.0 used the FreeBSD kernel somewhat differently and ran into a long standing problem: what it was doing should have been valid. None of the investigative update was to the jemalloc code. But it could be that, on review, tradeoff management could involve jemalloc code for all I know. As stands: /usr/src/sys/vm/vm_extern.h.orig /usr/src/sys/vm/vm_fault.c.orig /usr/src/sys/vm/vm_map.c.orig /usr/src/sys/vm/vm_object.c.orig /usr/src/sys/vm/vm_page.c.orig were created so that I could use them to restore my official pkgbase source (that is somewhat older). Side note: I've not sent this note to mmel at freebsd.org as it forwards to meloun.michal at gmail.com and: QUOTE Gmail has detected that this message 550-5.7.1 is likely unsolicited mail. To reduce the amount of spam sent to 550-5.7.1 Gmail, this message has been blocked. END QUOTE I'll see if a direct send gets the same treatment. === Mark Millard marklmi at yahoo.com
