On Fri, Sep 6, 2013 at 12:38 PM, Alfred Perlstein <alf...@freebsd.org>wrote:
> On 9/6/13 12:36 PM, hiren panchasara wrote: > >> On Fri, Sep 6, 2013 at 12:14 PM, Alfred Perlstein <bri...@mu.org> wrote: >> >> On 9/6/13 12:10 PM, hiren panchasara wrote: >>> >>> tunable_mbinit() in kern_mbuf.c looks like this: >>>> >>>> 119 /* >>>> 120 * The default limit for all mbuf related memory is 1/2 of >>>> all >>>> 121 * available kernel memory (physical or kmem). >>>> 122 * At most it can be 3/4 of available kernel memory. >>>> 123 */ >>>> 124 realmem = qmin((quad_t)physmem * PAGE_SIZE, >>>> 125 vm_map_max(kmem_map) - vm_map_min(kmem_map)); >>>> 126 maxmbufmem = realmem / 2; >>>> 127 TUNABLE_QUAD_FETCH("kern.ipc.****maxmbufmem", &maxmbufmem); >>>> >>>> 128 if (maxmbufmem > realmem / 4 * 3) >>>> 129 maxmbufmem = realmem / 4 * 3; >>>> >>>> If I am reading the code correctly, we loose the value on line 126 when >>>> we >>>> do FETCH on line 127. >>>> >>>> And after line 127, if we havent specified kern.ipc.maxmbufmem (in >>>> loader.conf - I guess...), we set that value to 0. >>>> >>>> And because of that the if condition on line 128 is almost always false? >>>> >>>> What am I missing here? >>>> >>>> Thanks, >>>> Hiren >>>> ______________________________****_________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/****mailman/listinfo/freebsd-net<http://lists.freebsd.org/**mailman/listinfo/freebsd-net> >>>> <h**ttp://lists.freebsd.org/**mailman/listinfo/freebsd-net<http://lists.freebsd.org/mailman/listinfo/freebsd-net> >>>> > >>>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@**fre** >>>> ebsd.org >>>> <http://freebsd.org><freebsd-net-**unsubscr...@freebsd.org<freebsd-net-unsubscr...@freebsd.org> >>>> > >>>> >>>> " >>>> >>>> I think TUNABLE_*_FETCH will only write to the variable if it >>>> explicitly >>>> >>> set. >>> >>> Meaning, unless the user actually sets a value in loader.conf then 127 is >>> a no-op. >>> >>> Thanks Navdeep and Alfred. >> >> Thats correct. Its not touching the var if its not set. >> >> I guess the other TUNABLE_INT_FETCHs later in the function checking for >> variable ==0 confused me. i.e. nmbclusters. >> >> 131 TUNABLE_INT_FETCH("kern.ipc.**nmbclusters", &nmbclusters); >> 132 if (nmbclusters == 0) >> 133 nmbclusters = maxmbufmem / MCLBYTES / 4; >> >> But those are global variable so here we are just checking if they are >> explicitly set of not. If not, we will set them. >> >> For maxmbufmem, we will set it to 1/2 the realmem. and if user sets it >> explicitly than we will make sure its not more than 3/4 of the realmem. >> > Yes. It's somewhat confusing. > > I'm all for adding comments to this effect if you have the time and > inclination. I guess its verbose enough in kern_mbuf.c I just had to *actually* read getenv_quad() to know that its not setting the variable to 0, it was just the return value. We can probably do: [hirenp@wholecorner ~/commit_head/sys/kern]$ svn diff Index: kern_environment.c =================================================================== --- kern_environment.c (revision 255320) +++ kern_environment.c (working copy) @@ -530,7 +530,8 @@ } /* - * Return a quad_t value from an environment variable. + * Return a quad_t value from an environment variable inside "data". + * If the environment variable is not set, "data" will be unchanged. */ int getenv_quad(const char *name, quad_t *data) cheers, Hiren _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"