Re: you broke current in some weird way... etc
While I haven't specifically tested this patch it looks reasonable to me. Are you going to do an engineering/commit cycle with it? -Matt Matthew Dillon <[EMAIL PROTECTED]> :The patch initializes nbuf (and many other things) statically again. :The only losses are slight bloat of the data section and the ability :... : :%%% :Index: subr_param.c :=== :RCS file: /home/ncvs/src/sys/kern/subr_param.c,v :retrieving revision 1.52 :diff -u -2 -r1.52 subr_param.c :--- subr_param.c 6 Feb 2002 01:19:19 - 1.52 :+++ subr_param.c 23 Feb 2002 07:44:45 - :@@ -56,31 +56,27 @@ : #define HZ 100 : #endif :-#define NPROC (20 + 16 * maxusers) :... : :Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: you broke current in some weird way... etc
On Wed, 27 Feb 2002, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Matthew Dillon writes:
> : Sometimes features in early boot can be adjusted by breaking into DDB
> : and w/l changing the sysctl variable, but perhaps not in this case.
>
> I think this is an excellent idea. I have many of these tunables in
> the cardbus/oldcard code and it has helped me to diagnose many
> problems. All my stuff runs after SI_SUB_TUNABLES, so that's not an
> issue. Of course, not much happens before SUB_TUNABLES, but Peter's
> changes look like they might be one of them.
Some older changes by Peter actually broke this feature. I ran into this
for nbuf. I set nbuf in ddb early (using a de-rotted version of db_elf.c
from the Attic to find nbuf since db_kld.c is too broken to work early),
but init_param.c undid the change.
The patch initializes nbuf (and many other things) statically again.
The only losses are slight bloat of the data section and the ability
to use non-constant expressions for certain macros if you #define them.
E.g., in -current you can #define NBUF in terms of maxusers although
that would be silly (I think physmem is not in scope so more sensible
definitions don't work). However, the patch retains the ability to
set MAXFILES using a funky expression. Most variables aren't ifdefed
uglyly enough to support this complication. E.g., the expression for
NPROC in terms of maxusers is fixed. The patch uses this expression
directly.
%%%
Index: subr_param.c
===
RCS file: /home/ncvs/src/sys/kern/subr_param.c,v
retrieving revision 1.52
diff -u -2 -r1.52 subr_param.c
--- subr_param.c6 Feb 2002 01:19:19 - 1.52
+++ subr_param.c23 Feb 2002 07:44:45 -
@@ -56,31 +56,27 @@
#defineHZ 100
#endif
-#defineNPROC (20 + 16 * maxusers)
#ifndef NBUF
-#define NBUF 0
-#endif
-#ifndef MAXFILES
-#defineMAXFILES (maxproc * 2)
+#defineNBUF 0
#endif
-inthz;
+inthz = HZ;
inttick;
-inttickadj; /* can adjust 30ms in 60s */
-intmaxusers; /* base tunable */
-intmaxproc;/* maximum # of processes */
-intmaxprocperuid; /* max # of procs per user */
-intmaxfiles; /* sys. wide open files limit */
-intmaxfilesperproc;/* per-proc open files limit */
-intncallout; /* maximum # of timer events */
-intnbuf;
+inttickadj;
+intmaxusers = MAXUSERS;/* base tunable */
+intmaxproc;/* maximum number of processes */
+intmaxprocperuid; /* max number of procs per user */
+intmaxfiles; /* system wide limit on open files */
+intmaxfilesperproc;/* per-process limit on open files */
+intncallout; /* maximum number of timer events */
+intnbuf = NBUF;
intnswbuf;
-intmaxswzone; /* max swmeta KVA storage */
-intmaxbcache; /* max buffer cache KVA storage */
-u_quad_t maxtsiz;/* max text size */
-u_quad_t dfldsiz;/* initial data size limit */
-u_quad_t maxdsiz;/* max data size */
-u_quad_t dflssiz;/* initial stack size limit */
-u_quad_t maxssiz;/* max stack size */
-u_quad_t sgrowsiz; /* amount to grow stack */
+intmaxswzone = VM_SWZONE_SIZE_MAX; /* max swmeta KVA storage */
+intmaxbcache = VM_BCACHE_SIZE_MAX; /* max buffer cache KVA storage */
+u_quad_t maxtsiz = MAXTSIZ;/* max text size */
+u_quad_t dfldsiz = DFLDSIZ;/* initial data size limit */
+u_quad_t maxdsiz = MAXDSIZ;/* max data size */
+u_quad_t dflssiz = DFLSSIZ;/* initial stack size limit */
+u_quad_t maxssiz = MAXSSIZ;/* max stack size */
+u_quad_t sgrowsiz = SGROWSIZ; /* amount to grow stack */
/*
@@ -92,5 +88,5 @@
/*
- * Boot time overrides that are not scaled against main memory
+ * Boot time overrides that are not scaled against main memory.
*/
void
@@ -98,34 +94,21 @@
{
- hz = HZ;
TUNABLE_INT_FETCH("kern.hz", &hz);
tick = 100 / hz;
tickadj = howmany(3, 60 * hz); /* can adjust 30ms in 60s */
-#ifdef VM_SWZONE_SIZE_MAX
- maxswzone = VM_SWZONE_SIZE_MAX;
-#endif
TUNABLE_INT_FETCH("kern.maxswzone", &maxswzone);
-#ifdef VM_BCACHE_SIZE_MAX
- maxbcache = VM_BCACHE_SIZE_MAX;
-#endif
TUNABLE_INT_FETCH("kern.maxbcache", &maxbcache);
- maxtsiz = MAXTSIZ;
TUNABLE_QUAD_FETCH("kern.maxtsiz", &maxtsiz);
- dfldsiz = DFLDSIZ;
TUNABLE_QUAD_FETCH("kern.dfldsiz", &dfldsiz);
- maxdsiz = MAXDSIZ;
TUNABLE_QUAD_FETCH("ker
Re: you broke current in some weird way... etc
:On Wed, Feb 27, 2002 at 09:33:48AM -0800, Matthew Dillon wrote: :> I'm just going to use this opportunity to plug the concept of tempora= :ry :> sysctl-instrumentation for a commit like this. =20 : :Any thoughts on having a root oid for sysctl oids like this, so they're :not forgotten, and aren't assumed by anyone to be permanent? : : tmp.foo.bar : :or similar? : :N We have a 'debug' OID, that's what I used for debug.critical_mode. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: you broke current in some weird way... etc
On Wed, Feb 27, 2002 at 09:33:48AM -0800, Matthew Dillon wrote: > I'm just going to use this opportunity to plug the concept of temporary > sysctl-instrumentation for a commit like this. Any thoughts on having a root oid for sysctl oids like this, so they're not forgotten, and aren't assumed by anyone to be permanent? tmp.foo.bar or similar? N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg35472/pgp0.pgp Description: PGP signature
Re: you broke current in some weird way... etc
In message <[EMAIL PROTECTED]> Matthew Dillon writes: : Sometimes features in early boot can be adjusted by breaking into DDB : and w/l changing the sysctl variable, but perhaps not in this case. I think this is an excellent idea. I have many of these tunables in the cardbus/oldcard code and it has helped me to diagnose many problems. All my stuff runs after SI_SUB_TUNABLES, so that's not an issue. Of course, not much happens before SUB_TUNABLES, but Peter's changes look like they might be one of them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: you broke current in some weird way... etc
Matthew Dillon wrote: > :> I'm just going to use this opportunity to plug the concept of temporary > :> sysctl-instrumentation for a commit like this. > : > :Overall, this is a good idea. However, it can't apply to > :any code that runs before init_main.c runs the SI_SUB_TUNABLES. > > Sure it does, because it means you can simply commit a change to the > default assignment for that sysctl rather then backing the whole thing > out to unbreak the general developer community. That saves a lot of > time and removes the 'oh hell, I have to track this down quickly!' > pressure. > > Sometimes features in early boot can be adjusted by breaking into DDB > and w/l changing the sysctl variable, but perhaps not in this case. Definitely not in this case. Similarly, there are a number of early allocations that occur by declaration, rather than by process, where the page mappings are then established post-facto, where it won't work. I really need to publish my "early life of FreeBSD" article. 8-(. I have all my extensive notes together, but I think it's at least a three-parter, and I need to expand the examples. I'll get around to it eventually, I promise. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: you broke current in some weird way... etc
:Matthew Dillon wrote: :> :date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191 :> :Back out all the pmap related stuff I've touched over the last few days. :> :There is some unresolved badness that has been eluding me, particularly :> :affecting uniprocessor kernels. Turning off PG_G helped (which is a bad :> :sign) but didn't solve it entirely. Userland programs still crashed. :> :> I'm just going to use this opportunity to plug the concept of temporary :> sysctl-instrumentation for a commit like this. : :Overall, this is a good idea. However, it can't apply to :any code that runs before init_main.c runs the SI_SUB_TUNABLES. : :-- Terry Sure it does, because it means you can simply commit a change to the default assignment for that sysctl rather then backing the whole thing out to unbreak the general developer community. That saves a lot of time and removes the 'oh hell, I have to track this down quickly!' pressure. Sometimes features in early boot can be adjusted by breaking into DDB and w/l changing the sysctl variable, but perhaps not in this case. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: you broke current in some weird way... etc
Matthew Dillon wrote: > :date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191 > :Back out all the pmap related stuff I've touched over the last few days. > :There is some unresolved badness that has been eluding me, particularly > :affecting uniprocessor kernels. Turning off PG_G helped (which is a bad > :sign) but didn't solve it entirely. Userland programs still crashed. > > I'm just going to use this opportunity to plug the concept of temporary > sysctl-instrumentation for a commit like this. Overall, this is a good idea. However, it can't apply to any code that runs before init_main.c runs the SI_SUB_TUNABLES. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: you broke current in some weird way... etc
:date: 2002/02/27 09:51:32; author: peter; state: Exp; lines: +245 -191 :Back out all the pmap related stuff I've touched over the last few days. :There is some unresolved badness that has been eluding me, particularly :affecting uniprocessor kernels. Turning off PG_G helped (which is a bad :sign) but didn't solve it entirely. Userland programs still crashed. I'm just going to use this opportunity to plug the concept of temporary sysctl-instrumentation for a commit like this. I'm not saying that sysctl instrumentation will catch such problems every time, or that it is appropriate in all cases, but if you had done it and turning off the sysctl had stopped the crashes you could have simply committed a change to the sysctl default. This would have stopped the breakage in the general community and give you time to track the problem down with the aid of those specific developers who reported the problem. This rather then backing out the entire commit which creates additional disruption and makes it difficult to solicit help from the people reporting the problem. I'm just going to contrast this with my critical_*() commit - the whiners that forced the backout aside, if the commit had stayed in and through normal developer testing was found to be buggy, the fact that it is instrumented would have (1) made validation of the bug easy, (2) allowed developers to get back to a working system without having to back anything out, and (3) it DID greatly improve my ability to follow-up with Ian to track the bug down, again without him having to back anything out. The length of time one keeps the instrumentation is heavily dependant on the feature being instrumented. For critical_*() I expect to keep the instrumentation intact only for a two or three months. For Giant wrappers I intend to keep it intact through the 5.0 release. Another example would be something like vfs.vmiodirenable. This sysctl allowed three or four developers to track down VMIO-backed directory bugs over a period of a year in stable without effecting our userbase. I recently made it the default and I'll probably remove the instrumentation entirely within the next two releases or so. I can't even begin guessing how much time and effort that sysctl has saved me. It's a win-win proposition. just a thought. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
