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