buildworld failed after deleting /usr/obj

[qroxana]

It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy.

--- all_subdir_usr.bin ---
--- objwarn ---
Warning: Object directory not changed from original 
/usr/src/usr.bin/clang/llvm-objcopy
--- COFF/COFFObjcopy.o ---
c++ -target aarch64-unknown-freebsd14.0 
--sysroot=/usr/obj/usr/src/arm64.aarch64/tmp 
-B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -fno-common 
-I/usr/src/usr.bin/clang/llvm-objcopy 
-I/usr/src/contrib/llvm-project/llvm/tools/llvm-objcopy 
-I/usr/obj/usr/src/arm64.aarch64/lib/clang/libllvm -I/usr/src/lib/clang/include 
-I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"aarch64-unknown-freebsd14.0\" 
-DLLVM_HOST_TRIPLE=\"aarch64-unknown-freebsd14.0\" -DDEFAULT_SYSROOT=\"\" 
-DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM 
-DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_RISCV 
-DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeAArch64AsmParser 
-DLLVM_NATIVE_ASMPRINTER=LLVMInitializeAArch64AsmPrinter 
-DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeAArch64Disassembler 
-DLLVM_NATIVE_TARGET=LLVMInitializeAArch64Target 
-DLLVM_NATIVE_TARGETINFO=LLVMInitializeAArch64TargetInfo 
-DLLVM_NATIVE_TARGETMC=LLVMInitializeAArch64TargetMC -ffunction-sections 
-fdata-sections -gline-tables-only -MD -MF.depend.COFF_COFFObjcopy.o 
-MTCOFF/COFFObjcopy.o -Wno-format-zero-length -fstack-protector-strong 
-Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch 
-Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses 
-Qunused-arguments -fno-exceptions -fno-rtti -std=c++14 -stdlib=libc++ 
-Wno-c++11-extensions -c 
/usr/src/contrib/llvm-project/llvm/tools/llvm-objcopy/COFF/COFFObjcopy.cpp -o 
COFF/COFFObjcopy.o
--- all_subdir_tests ---
--- objwarn ---
Warning: Object directory not changed from original /usr/src/tests/sys/fs/fusefs
--- bmap ---
(cd /usr/src/tests/sys/fs/fusefs && DEPENDFILE=.depend.bmap NO_SUBDIR=1 make -f 
Makefile _RECURSING_PROGS=t PROG=bmap PROG_CXX=bmap)
--- all_subdir_usr.sbin ---
--- all_subdir_usr.sbin/bsnmpd/modules/snmp_mibII ---
===> usr.sbin/bsnmpd/modules/snmp_mibII (all)
--- all_subdir_usr.bin ---
error: unable to open output file 'COFF/COFFObjcopy.o': 'No such file or 
directory'
1 error generated.
--- all_subdir_tests ---

make[3]: stopped in /usr/src
--- all_subdir_usr.sbin ---

make[3]: stopped in /usr/src
--- all_subdir_usr.bin ---

make[3]: stopped in /usr/src
--- all_subdir_lib ---

make[3]: stopped in /usr/src
329.31 real 244.62 user 54.49 sys

make[2]: stopped in /usr/src

make[1]: stopped in /usr/srcr

Re: An idea for swap partition size vs. swap space size in use handling

[Mark Millard]

On Jan 22, 2023, at 09:46, Mark Millard  wrote:
> 
>> On Jan 22, 2023, at 05:15, Mike Karels  wrote:
>> 
>>> On 22 Jan 2023, at 2:42, Mark Millard wrote:
>>> 
 On Jan 22, 2023, at 00:21, Mark Millard  wrote:
 
> On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:
> 
>> 
>> Mark Millard writes:
>> 
>>> It would be nice if I could have just one swap partition
>>> on a given boot media, one that is more than sufficient
>>> in size for all but the biggest RAM system --but to then
>>> be able to tell the system to just use up to the
>>> recommended swap space size and to ignore any extra swap
>>> space in the swap partition.
>>> 
>>> Why not just reduce the size of the swap partition to the desired size
>>> with “gpart resize”?  Granted, that requires manual intervention.
> 
> On Jan 22, 2023, at 05:15, Mike Karels  wrote:
> 
>> On 22 Jan 2023, at 2:42, Mark Millard wrote:
>> 
>>> On Jan 22, 2023, at 00:21, Mark Millard  wrote:
>>> 
 On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:
 
> 
> Mark Millard writes:
> 
>> It would be nice if I could have just one swap partition
>> on a given boot media, one that is more than sufficient
>> in size for all but the biggest RAM system --but to then
>> be able to tell the system to just use up to the
>> recommended swap space size and to ignore any extra swap
>> space in the swap partition.
>> 
>> Why not just reduce the size of the swap partition to the desired size
>> with “gpart resize”?  Granted, that requires manual intervention.
> 
> Why would I use the size for a 1 GiByte aarch64 system
> (prior boot) when I'm using the media to boot the 64
> GiByte system? So increases too. Manual intervention
> every time I move the media between systems, going in
> both directions over time?
> 
> That gets me into the business of independently
> calculating a reasonable lower bound for the recommended
> swap space every time I move the media between systems
> with differing amounts of RAM. I've noticed that the
> recommendation varies some across the OS updates. (My
> guess is variations in the kernel space use is involved
> in the recommendation.) I'm looking for something
> avoiding such a redundant calculation, something that
> just works given the variability across OS updates.

(And across platforms: armv7 and aarch64 have very
different recommendations for the same amount of
RAM. And across differing amounts of RAM from system
to system.)

Took a while for me to think of it, but there is also
that I use paths based on labels to identify the swap
partition independent of the system it is plugged into
and what other devices are present in that system.
(Some of the media here are USB media.)

Resizing (or subranging) partitions invalidates
labeling because the labeling information goes at the
end of the (logical) partition, if I understand right.
So labeling would have to be re-established for the
new size as well.


===
Mark Millard
marklmi at yahoo.com

Re: An idea for swap partition size vs. swap space size in use handling

[Mark Millard]

On Jan 22, 2023, at 06:11, Ronald Klop  wrote:
> 
> 
> Van: Mark Millard 
> Datum: zondag, 22 januari 2023 05:41
> Aan: freebsd-current 
> Onderwerp: An idea for swap partition size vs. swap space size in use handling
> I have boot media that are each set up to boot a variety
> of systems that have widely different RAM sizes, from
> 1 GiBytes to 64 GiBytes for the aarch64 examples of this.
> 
> This has lead to having multiple swap partitions of
> various sizes so that I can have total swap spaces that
> are somewhat under the recommended maximum sizes for the
> amount of RAM in each of those systems that a given media
> can boot.
> 
> It would be nice if I could have just one swap partition
> on a given boot media, one that is more than sufficient
> in size for all but the biggest RAM system --but to then
> be able to tell the system to just use up to the
> recommended swap space size and to ignore any extra swap
> space in the swap partition.
> 
> If such could be done, I'd no longer use multiple swap
> partitions at the same time in order to get to a desired
> total for the system at hand at the time.
> 
> Of course, that still leaves what to do when multiple
> swap partitions are enabled if such a "ignore what
> would be extra" mode was also enabled. As I'd not use
> such, I've no specific recommendations to make that
> would make any difference to my use.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> Â 
> 
> 
> Hi Mark,
> 
> Do you mean you would like to be able to add a "size" parameter to the fstab 
> swap line?
> 
> /dev/da0p1  noneswapsw,size=1g  0   0

No. That would use 1g for even the 64 GiByte RAM system
when I move the media to that 64 GiByte system and boot
it --and similarly as I move the media from system to
system in general.

For my style of use, I want the swap to be (a lower bound
approximation of) the recommended figure for the amount of
RAM for the specific system the media is currently use in.
That means that the figure changes when I move the media
to a system with a different amount of RAM.

> Another option I can think of is using the "gnop" geom provider. It has a -s 
> parameter to set the size.

I classically use a label based path to identify the swap
partition, not a device name. This fits with the variations
in what system I'm booting and what other devices might be
around. (Some of the media involved here are USB media.)
Labels go at the end of partitions, as I remember. This
would appear to make forms of resizing or subranging the
partition also mean adjusting the labeling. That is
something I'd like to avoid.

I'd also like to avoid needing to provide my own lower
bound approximation of the recommended figure for the
live amount of RAM. For one, it is platform dependent,
for example armv7 and aarch64 are very different for
the same amount of RAM.

===
Mark Millard
marklmi at yahoo.com

Re: An idea for swap partition size vs. swap space size in use handling

[Mark Millard]

On Jan 22, 2023, at 05:15, Mike Karels  wrote:

> On 22 Jan 2023, at 2:42, Mark Millard wrote:
> 
>> On Jan 22, 2023, at 00:21, Mark Millard  wrote:
>> 
>>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:
>>> 
 
 Mark Millard writes:
 
> It would be nice if I could have just one swap partition
> on a given boot media, one that is more than sufficient
> in size for all but the biggest RAM system --but to then
> be able to tell the system to just use up to the
> recommended swap space size and to ignore any extra swap
> space in the swap partition.
> 
> Why not just reduce the size of the swap partition to the desired size
> with “gpart resize”?  Granted, that requires manual intervention.

Why would I use the size for a 1 GiByte aarch64 system
(prior boot) when I'm using the media to boot the 64
GiByte system? So increases too. Manual intervention
every time I move the media between systems, going in
both directions over time?

That gets me into the business of independently
calculating a reasonable lower bound for the recommended
swap space every time I move the media between systems
with differing amounts of RAM. I've noticed that the
recommendation varies some across the OS updates. (My
guess is variations in the kernel space use is involved
in the recommendation.) I'm looking for something
avoiding such a redundant calculation, something that
just works given the variability across OS updates.


===
Mark Millard
marklmi at yahoo.com

Re: An idea for swap partition size vs. swap space size in use handling

[Ronald Klop]

Van: Mark Millard 
Datum: zondag, 22 januari 2023 05:41
Aan: freebsd-current 
Onderwerp: An idea for swap partition size vs. swap space size in use handling


I have boot media that are each set up to boot a variety
of systems that have widely different RAM sizes, from
1 GiBytes to 64 GiBytes for the aarch64 examples of this.

This has lead to having multiple swap partitions of
various sizes so that I can have total swap spaces that
are somewhat under the recommended maximum sizes for the
amount of RAM in each of those systems that a given media
can boot.

It would be nice if I could have just one swap partition
on a given boot media, one that is more than sufficient
in size for all but the biggest RAM system --but to then
be able to tell the system to just use up to the
recommended swap space size and to ignore any extra swap
space in the swap partition.

If such could be done, I'd no longer use multiple swap
partitions at the same time in order to get to a desired
total for the system at hand at the time.

Of course, that still leaves what to do when multiple
swap partitions are enabled if such a "ignore what
would be extra" mode was also enabled. As I'd not use
such, I've no specific recommendations to make that
would make any difference to my use.

===
Mark Millard
marklmi at yahoo.com

 







Hi Mark,

Do you mean you would like to be able to add a "size" parameter to the fstab 
swap line?

/dev/da0p1  noneswapsw,size=1g  0   0

Another option I can think of is using the "gnop" geom provider. It has a -s 
parameter to set the size.

Regards,
Ronald.
 

Re: An idea for swap partition size vs. swap space size in use handling

[Mike Karels]

On 22 Jan 2023, at 2:42, Mark Millard wrote:

> On Jan 22, 2023, at 00:21, Mark Millard  wrote:
>
>> On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:
>>
>>> 
>>> Mark Millard writes:
>>>
 It would be nice if I could have just one swap partition
 on a given boot media, one that is more than sufficient
 in size for all but the biggest RAM system --but to then
 be able to tell the system to just use up to the
 recommended swap space size and to ignore any extra swap
 space in the swap partition.

Why not just reduce the size of the swap partition to the desired size
with “gpart resize”?  Granted, that requires manual intervention.

Mike

>>> Last I looked at that code, that is precisely what happens
>>> if you add a too big swap-device ?
>>
>> It produces a notice reporting how much bigger what it is
>> using is than what is recommended, if I understand the
>> message right. Here is an example were the difference was
>> small for an armv7 context:
>>
>> warning: total configured swap (1003519 pages) exceeds maximum recommended 
>> amount (1003072 pages).
>>
>> Another from a context with a much bigger difference:
>>
>> warning: total configured swap (2097152 pages) exceeds maximum recommended 
>> amount (916632 pages).
>>
>> These sort of messages are followed by:
>>
>> warning: increase kern.maxswzone or reduce amount of swap.
>>
>> But, as I understand, increasing kern.maxswzone makes
>> tradoffs with other kernel memory use. man 8 loader
>> reports:
>
> All my references to "man 8 loader" should have been to
> "man 8 loader_simp" these days. (Old habit, not yet
> replaced.)
>
>> kern.maxswzone
>>   Limits the amount of KVM to be used to hold swap metadata,
>>   which directly governs the maximum amount of swap the
>>   system can support . . .
>> . . .
>>   Note that swap metadata can be fragmented, which means that
>>   the system can run out of space before it reaches the
>>   theoretical limit.  Therefore, care should be taken to not
>>   configure more swap than approximately half of the
>>   theoretical maximum.
>>
>> (Note: My understanding is that an "approximately half" is the
>> figure shown as the "recommended amount" in the warnings.)
>>
>>   Running out of space for swap metadata can leave the system
>>   in an unrecoverable state.  Therefore, you should only
>>   change this parameter if you need to greatly extend the KVM
>>   reservation for other resources such as the buffer cache or
>>   kern.ipc.nmbclusters.  Modifies kernel option
>>   VM_SWZONE_SIZE_MAX.
>>
>> The wording in man 8 loader is about decreasing kern.maxswzone
>
> Again.
>
>> in order to make room for other resources. But the implication
>> is that increases leave less room than normal for other
>> resources. I try to avoid getting the warnings as I do not have
>> knowledge/context to make well-guided tradeoffs for the
>> resources.
>>
>> As I understand, the 2097152 pages vs. 916632 pages example means
>> that it was operating with the referenced fragmentation problems
>> being more likely. That would not be true if it was just using
>> more like the 916632 pages and ignoring the rest.
>>
>> (I was not suggesting changes to default behavior. I was only
>> suggesting being able to put it in a mode where it would have
>> used, for example, just around 916632 pages of the swap space.)
>>
>>
>> (Note: Some of the detailed man 8 loader claims that I left out
>
> Again.
>
>> seem to not be general to all platforms, despite the wording
>> giving no hint of that issue.)
>
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com

Re: An idea for swap partition size vs. swap space size in use handling

[Mark Millard]

On Jan 22, 2023, at 00:21, Mark Millard  wrote:

> On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:
> 
>> 
>> Mark Millard writes:
>> 
>>> It would be nice if I could have just one swap partition
>>> on a given boot media, one that is more than sufficient
>>> in size for all but the biggest RAM system --but to then
>>> be able to tell the system to just use up to the
>>> recommended swap space size and to ignore any extra swap
>>> space in the swap partition.
>> 
>> Last I looked at that code, that is precisely what happens
>> if you add a too big swap-device ?
> 
> It produces a notice reporting how much bigger what it is
> using is than what is recommended, if I understand the
> message right. Here is an example were the difference was
> small for an armv7 context:
> 
> warning: total configured swap (1003519 pages) exceeds maximum recommended 
> amount (1003072 pages).
> 
> Another from a context with a much bigger difference:
> 
> warning: total configured swap (2097152 pages) exceeds maximum recommended 
> amount (916632 pages).
> 
> These sort of messages are followed by:
> 
> warning: increase kern.maxswzone or reduce amount of swap.
> 
> But, as I understand, increasing kern.maxswzone makes
> tradoffs with other kernel memory use. man 8 loader
> reports:

All my references to "man 8 loader" should have been to
"man 8 loader_simp" these days. (Old habit, not yet
replaced.)

> kern.maxswzone
>   Limits the amount of KVM to be used to hold swap metadata,
>   which directly governs the maximum amount of swap the
>   system can support . . .
> . . .
>   Note that swap metadata can be fragmented, which means that
>   the system can run out of space before it reaches the
>   theoretical limit.  Therefore, care should be taken to not
>   configure more swap than approximately half of the
>   theoretical maximum.
> 
> (Note: My understanding is that an "approximately half" is the
> figure shown as the "recommended amount" in the warnings.)
> 
>   Running out of space for swap metadata can leave the system
>   in an unrecoverable state.  Therefore, you should only
>   change this parameter if you need to greatly extend the KVM
>   reservation for other resources such as the buffer cache or
>   kern.ipc.nmbclusters.  Modifies kernel option
>   VM_SWZONE_SIZE_MAX.
> 
> The wording in man 8 loader is about decreasing kern.maxswzone

Again.

> in order to make room for other resources. But the implication
> is that increases leave less room than normal for other
> resources. I try to avoid getting the warnings as I do not have
> knowledge/context to make well-guided tradeoffs for the
> resources.
> 
> As I understand, the 2097152 pages vs. 916632 pages example means
> that it was operating with the referenced fragmentation problems
> being more likely. That would not be true if it was just using
> more like the 916632 pages and ignoring the rest.
> 
> (I was not suggesting changes to default behavior. I was only
> suggesting being able to put it in a mode where it would have
> used, for example, just around 916632 pages of the swap space.)
> 
> 
> (Note: Some of the detailed man 8 loader claims that I left out

Again.

> seem to not be general to all platforms, despite the wording
> giving no hint of that issue.)




===
Mark Millard
marklmi at yahoo.com

Re: An idea for swap partition size vs. swap space size in use handling

[Mark Millard]

On Jan 21, 2023, at 23:17, Poul-Henning Kamp  wrote:

> 
> Mark Millard writes:
> 
>> It would be nice if I could have just one swap partition
>> on a given boot media, one that is more than sufficient
>> in size for all but the biggest RAM system --but to then
>> be able to tell the system to just use up to the
>> recommended swap space size and to ignore any extra swap
>> space in the swap partition.
> 
> Last I looked at that code, that is precisely what happens
> if you add a too big swap-device ?

It produces a notice reporting how much bigger what it is
using is than what is recommended, if I understand the
message right. Here is an example were the difference was
small for an armv7 context:

warning: total configured swap (1003519 pages) exceeds maximum recommended 
amount (1003072 pages).

Another from a context with a much bigger difference:

warning: total configured swap (2097152 pages) exceeds maximum recommended 
amount (916632 pages).

These sort of messages are followed by:

warning: increase kern.maxswzone or reduce amount of swap.

But, as I understand, increasing kern.maxswzone makes
tradoffs with other kernel memory use. man 8 loader
reports:

 kern.maxswzone
   Limits the amount of KVM to be used to hold swap metadata,
   which directly governs the maximum amount of swap the
   system can support . . .
. . .
   Note that swap metadata can be fragmented, which means that
   the system can run out of space before it reaches the
   theoretical limit.  Therefore, care should be taken to not
   configure more swap than approximately half of the
   theoretical maximum.

(Note: My understanding is that an "approximately half" is the
figure shown as the "recommended amount" in the warnings.)

   Running out of space for swap metadata can leave the system
   in an unrecoverable state.  Therefore, you should only
   change this parameter if you need to greatly extend the KVM
   reservation for other resources such as the buffer cache or
   kern.ipc.nmbclusters.  Modifies kernel option
   VM_SWZONE_SIZE_MAX.

The wording in man 8 loader is about decreasing kern.maxswzone
in order to make room for other resources. But the implication
is that increases leave less room than normal for other
resources. I try to avoid getting the warnings as I do not have
knowledge/context to make well-guided tradeoffs for the
resources.

As I understand, the 2097152 pages vs. 916632 pages example means
that it was operating with the referenced fragmentation problems
being more likely. That would not be true if it was just using
more like the 916632 pages and ignoring the rest.

(I was not suggesting changes to default behavior. I was only
suggesting being able to put it in a mode where it would have
used, for example, just around 916632 pages of the swap space.)


(Note: Some of the detailed man 8 loader claims that I left out
seem to not be general to all platforms, despite the wording
giving no hint of that issue.)

===
Mark Millard
marklmi at yahoo.com