Dag-Erling Smørgrav wrote:
> Loader I/O performance is much better these days so loading modules
> pre-boot doesn't slow the boot down much any more, but it's still more
That depends very much on the h/w, especially the storage attachment.
None of which applies to any machine likely to be using
On Tue, Jul 30, 2024 at 10:02:37PM -0600, Warner Losh wrote:
> On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote:
>
> > Miroslav Lachman <000.f...@quip.cz> writes:
> > > I'm a bit confused. If I understand it right, you say loader.conf
> > > causes less memory fragmentation, but DES said "
On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote:
> Miroslav Lachman <000.f...@quip.cz> writes:
> > I'm a bit confused. If I understand it right, you say loader.conf
> > causes less memory fragmentation, but DES said "it still increases low
> > memory fragmentation". So what is true? And
> On Jul 31, 2024, at 2:54 AM, Dag-Erling Smørgrav wrote:
>
> Miroslav Lachman <000.f...@quip.cz> writes:
>> I'm a bit confused. If I understand it right, you say loader.conf
>> causes less memory fragmentation, but DES said "it still increases low
>> memory fragmentation". So what is true? An
On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote:
"Poul-Henning Kamp" writes:
Dag-Erling Smørgrav writes:
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
Apart from the internals of config
Miroslav Lachman <000.f...@quip.cz> writes:
> I'm a bit confused. If I understand it right, you say loader.conf
> causes less memory fragmentation, but DES said "it still increases low
> memory fragmentation". So what is true? And is this something to watch
> out for, or is memory fragmentation not
On Tue, Jul 30, 2024 at 11:57:07PM +0900, Tomoaki AOKI wrote:
Another aspect is that loading multiple too large modules easily makes
boots crash. Staging area (memory region which loader allocates to load
kernel and modules, and maybe configured buffers) is limited.
This is why I went looking
On 30/07/2024 16:30, Warner Losh wrote:
[..]
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any
problems
it used to solve are solved, and that the preferred way is to load
everything from load
On Tue, 30 Jul 2024 19:22:31 +0800
Alastair Hogge wrote:
>
>
> On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
> >On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> >> Gary Jennejohn writes:
> >
> >[..]
> >
> >>> I also load it from /boot/loader.conf using filemon_lo
On Tue, Jul 30, 2024, 4:50 AM Poul-Henning Kamp wrote:
>
> Dag-Erling Smørgrav writes:
>
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
>
> Apart from the internals of con
On Tue, Jul 30, 2024, 3:39 AM Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at boot time, but it
On 30/07/2024 12:31, Dag-Erling Smørgrav wrote:
Miroslav Lachman <000.f...@quip.cz> writes:
Dag-Erling Smørgrav writes:
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation.
Does this also apply today? I recently re
On 30/07/2024 14:55, Michael Gmelin wrote:
On Tue, 30 Jul 2024 11:38:57 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:
[..]
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any
problems it used to solve are so
On Tue, 30 Jul 2024 11:38:57 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at bo
"Poul-Henning Kamp" writes:
> Dag-Erling Smørgrav writes:
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
> Apart from the internals of config(8) and it's input data, is there
> any
On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
>On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
>> Gary Jennejohn writes:
>
>[..]
>
>>> I also load it from /boot/loader.conf using filemon_load="YES"
>>
>> This does cause the module to be loaded at boot time, but it
Dag-Erling Smørgrav writes:
> There is very little difference between options and devices in kernel
> configuration files, but for what it's worth, filemon is a device, not
> an option.
Apart from the internals of config(8) and it's input data, is there
any actual difference left ?
--
On Tue, 30 Jul 2024 11:10:06 +0200
Dag-Erling Smørgrav wrote:
> Gary Jennejohn writes:
> > filemon is not a device, it's an option. So you can't have "device
> > filemon" in your kernel config file.
>
> There is very little difference between options and devices in kernel
> configuration files,
Miroslav Lachman <000.f...@quip.cz> writes:
> Dag-Erling Smørgrav writes:
> > This does cause the module to be loaded at boot time, but it's slower
> > than loading it later, and it increases memory fragmentation.
> Does this also apply today? I recently read from someone on a mailing
> list that
Hi,
On Tue, 30 Jul 2024, at 10:10, Dag-Erling Smørgrav wrote:
> void writes:
>> How would I go about remedying the issue that usage/examples
>> are not present in manpages for either the device line in kernel
>> config or filemon.ko ?
>
> https://reviews.freebsd.org/D46184
thank you!
On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
Gary Jennejohn writes:
[..]
I also load it from /boot/loader.conf using filemon_load="YES"
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation. A better
option is
void writes:
> How would I go about remedying the issue that usage/examples
> are not present in manpages for either the device line in kernel
> config or filemon.ko ?
https://reviews.freebsd.org/D46184
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Gary Jennejohn writes:
> filemon is not a device, it's an option. So you can't have "device
> filemon" in your kernel config file.
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
> I compile
How would I go about remedying the issue that usage/examples
are not present in manpages for either the device line
in kernel config or filemon.ko ?
--
On Sat, 27 Jul 2024 19:31:37 +0100
void wrote:
> On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
>
> >filemon is not a device, it's an option. So you can't have "device
> >filemon" in your kernel config file.
> >
> >I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in
Marek Zarychta wrote:
>
> What about filesystem perfomnace ? Have you benchmarked your FS and
> whole system with and without filemon loaded ?
FWIW filemon does nothing unless make opens the device.
and then it only impacts syscalls done by that pid and its children.
> I am not questionining t
slightly tangent question but does filemon and consequently
WITH_META_MODE=YES work, when /usr/obj is on tmpfs? In my test, it is not
and i tested without reboot, so /usr/obj is not removed. Reason is to avoid
disk use when building world/kernel.
On Sat, Jul 27, 2024 at 6:35 PM void wrote:
> On
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
filemon is not a device, it's an option. So you can't have "device
filemon" in your kernel config file.
man 4 filemon has the following
NAME
filemon – the filemon device
[...]
DESCRIPTION
The filemon device allows a
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote:
filemon is not a device, it's an option. So you can't have "device
filemon" in your kernel config file.
I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my
kernel config file.
What's the actual line in your kernel
Dnia Sat, Jul 27, 2024 at 03:27:19PM +0100, Nuno Teixeira napisał(a):
> Hello,
>
> I use filemon for builds with WITH_META_MODE loaded from rc.conf:
> kld_list="... filemon" for some years on both amd64 and aarch64.
What about filesystem perfomnace ? Have you benchmarked your FS and
whole system
On Sat, 27 Jul 2024 15:27:19 +0100
Nuno Teixeira wrote:
> Hello,
>
> I use filemon for builds with WITH_META_MODE loaded from rc.conf:
> kld_list="... filemon" for some years on both amd64 and aarch64.
>
> Cheers,
>
> void escreveu (sábado, 27/07/2024 à(s) 14:50):
>
> > Is it better to load file
Hello,
I use filemon for builds with WITH_META_MODE loaded from rc.conf:
kld_list="... filemon" for some years on both amd64 and aarch64.
Cheers,
void escreveu (sábado, 27/07/2024 à(s) 14:50):
> Is it better to load filemon as kldload filemon, or to
> have it set as a device via 'device filemo
> On Jul 27, 2024, at 9:49 PM, void wrote:
>
> Is it better to load filemon as kldload filemon, or to
> have it set as a device via 'device filemon' in the kernel config file? or to
> just load it when rebuilding the system?
>
> There is man 4 filemon but nothing there to describe usage as .
Am Mon, 8 May 2017 12:39:12 -0700
"Simon J. Gerraty" schrieb:
> O. Hartmann wrote:
> > > .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> > >
> > > --sjg
> >
> > I suppose I have to set this flag in
> >
> > /etc/src-env.conf
>
> That should work.
> Let us know how it goes
>
David Wolfskill wrote:
> I placed it in /etc/src.conf; thus:
>
> g1-252(11.0-S)[1] cat /etc/src.conf
> KERNCONF=CANARY
> PORTS_MODULES=x11/nvidia-driver-340
> .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> WITHOUT_DEBUG_FILES=1
> IWN_DEBUG=1
> IEEE80211_DEBUG=1
> WITH_ELFCOPY_AS_OBJCOPY=1
On Mon, May 08, 2017 at 07:32:58PM +0200, O. Hartmann wrote:
> Am Mon, 8 May 2017 10:17:05 -0700
> "Simon J. Gerraty" schrieb:
> ...
> > bmake has a set of knobs for telling it to ignore things.
> > OP try
> >
> > .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> >
> > --sjg
>
> I suppose I
O. Hartmann wrote:
> > .MAKE.META.IGNORE_PATHS += /usr/local/etc/libmap.d
> >
> > --sjg
>
> I suppose I have to set this flag in
>
> /etc/src-env.conf
That should work.
Let us know how it goes
___
freebsd-current@freebsd.org mailing list
https://lis
Am Mon, 8 May 2017 11:23:01 -0700
"Ngie Cooper (yaneurabeya)" schrieb:
> > On May 6, 2017, at 00:22, O. Hartmann wrote:
> >
> > I build CURRENT on two technically similar systems on a almost daily basis.
> > Therefore, it was a great relief having WITH_META_MODE=yes set in
> > /etc/src-env.con
> On May 6, 2017, at 00:22, O. Hartmann wrote:
>
> I build CURRENT on two technically similar systems on a almost daily basis.
> Therefore, it
> was a great relief having WITH_META_MODE=yes set in /etc/src-env.conf for
> incremental
> builds. To make my understanding of this clear (just in cas
Am Mon, 8 May 2017 19:32:58 +0200
"O. Hartmann" schrieb:
> Am Mon, 8 May 2017 10:17:05 -0700
> "Simon J. Gerraty" schrieb:
>
> > Konstantin Belousov wrote:
> > > If I understand the motto of meta-mode, any file change is detected for
> > > any
> > > file accessed during the build. All dyna
Am Mon, 8 May 2017 10:17:05 -0700
"Simon J. Gerraty" schrieb:
> Konstantin Belousov wrote:
> > If I understand the motto of meta-mode, any file change is detected for any
> > file accessed during the build. All dynamically-linked binary includes
> > the rtld into the process image, and rtld rea
Konstantin Belousov wrote:
> If I understand the motto of meta-mode, any file change is detected for any
> file accessed during the build. All dynamically-linked binary includes
> the rtld into the process image, and rtld reads all config files in the
> libmap.d subdirectories. The end result is
On Mon, May 08, 2017 at 09:04:08AM -0700, Simon J. Gerraty wrote:
> O. Hartmann wrote:
> > It is weird!
> >
> > Today, after yesterday's built, I face the same 90 minutes build horror
> > again, this time
> > I switched on "-dM" with the make command.
> >
> > This happens:
> >
> > [...]
> > /u
O. Hartmann wrote:
> It is weird!
>
> Today, after yesterday's built, I face the same 90 minutes build horror
> again, this time
> I switched on "-dM" with the make command.
>
> This happens:
>
> [...]
> /usr/obj/usr/src/lib/clang/libllvm/_usr_obj_usr_src_lib_clang_libllvm_CodeGen_SelectionDAG
Am Sun, 7 May 2017 23:24:55 -0700
"Simon J. Gerraty" schrieb:
> Hi,
>
> > I build CURRENT on two technically similar systems on a almost daily basis.
> > Therefore, it was a great relief having WITH_META_MODE=yes set in
> > /etc/src-env.conf
> > for incremental builds. To make my understanding
Hi,
> I build CURRENT on two technically similar systems on a almost daily basis.
> Therefore, it
> was a great relief having WITH_META_MODE=yes set in /etc/src-env.conf for
> incremental
> builds. To make my understanding of this clear (just in case I'm wrong):
> setting
> WITH_META_MODE build
46 matches
Mail list logo
