mbuf autotuning changes

[hiren panchasara]

On Fri, Sep 6, 2013 at 12:38 PM, Alfred Perlstein <alfred at freebsd.org>wrote:

> On 9/6/13 12:36 PM, hiren panchasara wrote:
>
>> On Fri, Sep 6, 2013 at 12:14 PM, Alfred Perlstein <bright at 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 at 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-**unsubscribe at freebsd.org<freebsd-net-unsubscribe at 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 at 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