Date: Fri, 6 Sep 2013 13:09:23 -0700 From: hiren panchasara <hiren.panchasara@gmail.com> To: Alfred Perlstein <alfred@freebsd.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: mbuf autotuning changes Message-ID: <CALCpEUF8=NS1EsCjRxJd2QRwe0S97OoP-J7NaYDnmAO5B2r25Q@mail.gmail.com> In-Reply-To: <522A2F2E.8080808@freebsd.org> References: <CALCpEUFxaXKh4%2B8evratZYE3JyfyTmrL7rzpBqUJ%2B_S3Ff-AcA@mail.gmail.com> <522A2993.6020206@mu.org> <CALCpEUFtAk7DRA27D=mZoEbO-8cYh45y6Go8g8q8u6d%2BWJVLLw@mail.gmail.com> <522A2F2E.8080808@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 6, 2013 at 12:38 PM, Alfred Perlstein <alfred@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@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-**unsubscribe@freebsd.org<freebsd-net-unsubscribe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALCpEUF8=NS1EsCjRxJd2QRwe0S97OoP-J7NaYDnmAO5B2r25Q>