kely to be using filemon of
course.
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 t
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
for filemon as kernel device in the manpage
initially.
Generally, in the kernel config I'll comment out stuff thats not going to be
used
and add stuff i know is needed, instead of using loader.conf or other methods.
--
loader.conf. So I'm curious, what's the right thing to
do then? (I load most of my modules from rc.conf)
Either or for filemon. Either rc.conf's kld_list or loader.conf's
filemon_load=YES. I've been recommending loader.conf since there's
slightly less memory fragm
gt; >>> 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
> >> op
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.
is 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 to include "filemon" in the kld_list variable in /etc/rc.conf
> > or /etc/rc.conf.d/kld. For instance,
> &
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
;
> > 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 to include "filemon" in the
> > kld_list variable in /etc/rc.conf or /etc/rc.conf.d/kld. For
&g
"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
is 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 to include "filemon" in the kld_list variable in /etc/rc.conf
>> or /etc/rc.conf.d/kld. For instance,
>>
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 act
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 an
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!
A better
option is to include "filemon" in the kld_list variable in /etc/rc.conf
or /etc/rc.conf.d/kld. For instance,
% cat /etc/rc.conf.d/kld/filemon
kld_list="${kld_list} filemon"
Does this also apply today? I recently read from someone on a mailing
list that t
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 devi
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
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 q
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 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 fil
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.
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 yo
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)
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 de
> 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 not
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 .ko
or device. System is n271321-9ae91f59c500 on arm64.
--
On 5/10/17 1:12 AM, O. Hartmann wrote:
> hello,
>
> building a release of most recent 12-CURRENT seems to be at some point very
> annoying. When building the main host's system out of /usr/src
> using /etc/src-env.conf set with WITH_META_MODE=yes, build time decreases
> significantly. Now I perfor
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
hello,
building a release of most recent 12-CURRENT seems to be at some point very
annoying. When building the main host's system out of /usr/src
using /etc/src-env.conf set with WITH_META_MODE=yes, build time decreases
significantly. Now I perform some tasks building release. The source tree is
1
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
bsd.mkopt.mk processes them in a specified
> order.
>
> > The problem: to make my point clear: the "weak" box starts compiling almost
> > everytime
> > now the LLVM/CLANG tree while the XEON box does not. This is spooky.
>
> Add -dM, and see if that tells
esses them in a specified
order.
> The problem: to make my point clear: the "weak" box starts compiling almost
> everytime now
> the LLVM/CLANG tree while the XEON box does not. This is spooky.
Add -dM, and see if that tells you why.
Also confirm that filemon is getting loaded af
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 builds only portions that
On 6/4/2016 12:17 AM, Mark Millard wrote:
> On 2016-Jun-2, at 12:36 PM, Bryan Drewery wrote:
>
>> On 6/1/2016 6:39 PM, Mark Millard wrote:
>>> while filemon.ko now exists:
>>>> # ls -l /boot/*/filemon*
>>>> -r-xr-xr-x 1 root wheel 32064 Jun 1
On 2016-Jun-2, at 12:36 PM, Bryan Drewery wrote:
> On 6/1/2016 6:39 PM, Mark Millard wrote:
>> while filemon.ko now exists:
>>> # ls -l /boot/*/filemon*
>>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko
>> it does not load:
>>> #
On 6/1/2016 6:39 PM, Mark Millard wrote:
> while filemon.ko now exists:
>> # ls -l /boot/*/filemon*
>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko
> it does not load:
>> # kldload -n filemon
>> kldload: can't load filemon: No such
On Wed, Jun 1, 2016 at 8:59 PM, Bryan Drewery wrote:
> On 6/1/2016 6:39 PM, Mark Millard wrote:
>> while filemon.ko now exists:
>>> # ls -l /boot/*/filemon*
>>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko
>> it does not load:
>>&g
On 2016-Jun-1, at 7:21 PM, Bryan Drewery wrote:
>
> The fix is easy, I am just wondering why there are 2 ABI formats
> supported. If only one is normally used and the default then I'll only
> support that one.
>
> Filemon hooks the syscall table.
The only differences t
The fix is easy, I am just wondering why there are 2 ABI formats
supported. If only one is normally used and the default then I'll only
support that one.
Filemon hooks the syscall table.
On 6/1/2016 7:16 PM, Mark Millard wrote:
> May be Nathan Whitehorn knows what is going on that
filemon.ko is required in order for
WITH_META_MODE=yes to work for incremental builds.
===
Mark Millard
markmi at dsl-only.net
On 2016-Jun-1, at 6:59 PM, Bryan Drewery wrote:
> On 6/1/2016 6:39 PM, Mark Millard wrote:
>> while filemon.ko now exists:
>>> # ls -l /boot/*/filemon*
On 6/1/2016 6:39 PM, Mark Millard wrote:
> while filemon.ko now exists:
>> # ls -l /boot/*/filemon*
>> -r-xr-xr-x 1 root wheel 32064 Jun 1 17:59 /boot/kernel/filemon.ko
> it does not load:
>> # kldload -n filemon
>> kldload: can't load filemon: No such
[A top-posted error report for powerpc64.]
On 2016-Jun-1, at 8:20 AM, Bryan Drewery wrote:
> I've just enabled the filemon(4) build on all architectures in r301130.
But on (built via powerpc64-gcc on the powerpc64 box):
> # uname -apKU
> FreeBSD FBSDG5C0 11.0-ALPHA1 FreeBSD 1
59 matches
Mail list logo
