Date: Tue, 05 Feb 2002 19:48:06 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Mike Smith <msmith@hub.freebsd.org> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Setting sysctl(8)'s in rc.conf Message-ID: <3C60A776.F4B0F660@mindspring.com> References: <20020205191105.A25310@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote:
> > > A better approach would be to make those items that are sysctls in
> > > modules also TUNABLES, and then the problem goes away.
> >
> > Will this let them be set before load?
>
> Why not go read up on tunables?
>
> /*
> * Infrastructure for tunable 'constants'. Value may be specified at compile
> * time or kernel load time. Rules relating tunables together can be placed
> * in a SYSINIT function at SI_SUB_TUNABLES with SI_ORDER_LAST.
> */
It still doesn't tell me if I can set them before I load
a particular *kernel module*, which was the context in
which the question was asked.
I think it can be done, as long as it is not done on a
SYSCTL declared variable, which is a BSS initialization.
> > There's a bad assumption in tunables, that they may be
> > tuned after boot time, which is not true for things
> > like sizes of zalloci() zones, which must be contiguous,
>
> There is? Since you don't actually know what TUNABLEs actually are,
> aren't you going out on a bit of a limb here?
No, I know what they are; you were just misunderstanding
my previous questions context.
The tunables are fetched later in the boot process than
some initializations and allocations (e.g. anything
before SI_UB_TUNABLES, which is most of the boot process).
For example, none of the allocations in locore.s can be
changed via a tunable, and they are some of the most
interesting ones to want to change.
If you'll remember, I was the one that provided the patch
for the tunable tuning of the maxsockets and maxfiles and
seperate tuning for max udp and tcp sockets, and wrote the
SYSINIT and init_main.c code, which is what results in the
SI_SUB_TUNABLES call occuring at all.
> With regard to the original suggestion, I'm not in agreement that
> module arguments should be tunables either. Many module arguments
> should actually be hints (since they relate to instances of something
> supported by a module). Those that are truly generic, or in the case
> of a module which only creates a single instance should be passed at
> module load time either directly (as with the loader's 'load' command,
> via kldload, etc) or indirectly from a configuration file.
>
> TUNABLEs really exist to deal with the problem described above, not
> the issue of module arguments.
This is really the heart of the problem at hand: how do
I do a tunable that I set in the loader that then effects
the behaviour of, for example, ipfw.ko.
The implication is that anything that is SYSCTL'able would
need to go into the TUNABLE space; we can dismiss this idea
(below), but we will find that we should try to make this
as true as we can, anyway.
The problem here is that you don't want to imply that you
can change something you are OK to change at boot time, at
runtime, when it's not OK.
The other problem is that there are things that *aren't*
tunable, and will always remain compile time. You aren't
going to be able to change anything used before the call
at SI_SUB_TUNABLES runs, and be able to expect a loader
value change to have effect.
So really, there are several sets of options:
[ CTVs (compile time values) ]
[ CTVs after SI_SUB_TUNABLES ]
[ tunables ]
[ readable sysctls ]
[ read/write sysctls ]
[ invisible]
(the reverse overlap on tunables vs. read/write sysctls is
because there are some things that are set before the call
to SI_SUB_TUNABLES that can be reset via sysctl anyway)
It makes sense to me to want to expose the entire set of
tunables into the sysctl space, at all times.
It also makes some sense to consider the tunables as "boot
environment" -- that is, that you can set environment
variables in the loader, which may or may not be used later
by a module that is loaded (perhaps weeks) later.
This kind of implies a need to break up the name space
by module, rather than by function provided by the module,
to avoid collisions.
There is still a missing chunk, which is the ability to
access this space before the SI_SUB_TUNABLES space, early
on in the boot initialization process. I view this as
"work to do".
Also, some things will still never be tunable, e.g. you could
tune the KVA space size, if you were willing to make the
loader itself respect some tunables, like kernel base address,
and PIC the entire kernel code, but doing this would make
things run slower, since it is a well known (but infrequently
revisited) assumption that PIC code is slower than absolute
code.
I would like to see several things:
1) Tunables treated as an environment
2) No tunables hidden from sysctl space
3) Seperation of tunables name space by module,
rather than by function, if such modules are
optional
4) Tunables respected at the start of the boot
process, rather than after SI_SUB_TUNABLES
5) A more clear border between read-only and
read-write (e.g. upping "maxfiles" does not
up the number of network connections, because
it does not change inpcb and tcpcb pool sizes,
which are not adjustable at runtime, only at
boot time).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C60A776.F4B0F660>