On 11/18/12 6:13 PM, Andre Oppermann wrote:
> On 18.11.2012 15:05, Andrey Zonov wrote:
>> On 11/11/12 3:04 AM, Andre Oppermann wrote:
>>> On 10.11.2012 23:24, Alfred Perlstein wrote:
On 11/10/12 11:18 AM, Andre Oppermann wrote:
> On 10.11.2012 19:04, Peter Wemm wrote:
>> This is compli
On 18.11.2012 15:05, Andrey Zonov wrote:
On 11/11/12 3:04 AM, Andre Oppermann wrote:
On 10.11.2012 23:24, Alfred Perlstein wrote:
On 11/10/12 11:18 AM, Andre Oppermann wrote:
On 10.11.2012 19:04, Peter Wemm wrote:
This is complicated but we need a simple user visible view of it. It
really ne
On 11/11/12 3:04 AM, Andre Oppermann wrote:
> On 10.11.2012 23:24, Alfred Perlstein wrote:
>> On 11/10/12 11:18 AM, Andre Oppermann wrote:
>>> On 10.11.2012 19:04, Peter Wemm wrote:
This is complicated but we need a simple user visible view of it. It
really needs to be something like "nm
On 11/11/12 12:31 PM, Adrian Chadd wrote:
On 11 November 2012 09:11, Alfred Perlstein wrote:
Oh, OK, I didn't know it was so involved. I probably don't have anything to
worry about then. :)
Nono - I want you to worry about it. But _I_ want there to be a
slightly longer term goal that's less ab
On 11 November 2012 09:11, Alfred Perlstein wrote:
> Oh, OK, I didn't know it was so involved. I probably don't have anything to
> worry about then. :)
Nono - I want you to worry about it. But _I_ want there to be a
slightly longer term goal that's less about dictating policy in the
kernel and mo
Oh, OK, I didn't know it was so involved. I probably don't have anything
to worry about then. :)
-Alfred
On 11/11/12 8:52 AM, Adrian Chadd wrote:
Alfred,
You're thinking about it one step ahead, not 5 steps ahead.
One step ahead: "let's fix maxuser scaling."
5 steps ahead: "Let's find all o
I think there are two issue here.
One: you have much better idea of how to tune nmbclusters than I do. Cool!
Please put that into the code. I really think that's great and the time you've
pit into giving it serious thought is helpful to all.
Two: you want to divorce nmbclusters (and therefor
Alfred,
You're thinking about it one step ahead, not 5 steps ahead.
One step ahead: "let's fix maxuser scaling."
5 steps ahead: "Let's find all of the non-dynamic things that maxusers
scales, figure out how to make them run-time tunable, and then make a
maxusers.sh user-land script that scales t
On Sun, Nov 11, 2012 at 1:41 AM, Albert Perlstein wrote:
> The real conversation goes like this:
>
> user: "Why is my box seeing terrible network performance?"
> bsdguy: "Increase nmbclusters."
> user: "what is that?"
> bsdguy: "Oh those are the mbufs, just tell me your current value."
> user: "oh
On Sun, Nov 11, 2012 at 1:41 AM, Alfred Perlstein wrote:
> On 11/10/12 11:33 PM, Alexey Dokuchaev wrote:
>>
>> On Sat, Nov 10, 2012 at 10:22:52PM -0800, Peter Wemm wrote:
>>>
>>> We've had kern.ipc.nmbclusters for years. It is simple to understand,
>>> easy to predict the outcome of a change, is
On 11/10/12 11:33 PM, Alexey Dokuchaev wrote:
On Sat, Nov 10, 2012 at 10:22:52PM -0800, Peter Wemm wrote:
We've had kern.ipc.nmbclusters for years. It is simple to understand,
easy to predict the outcome of a change, is runtime adjustable, is a
*cap* and not a reservation (like it used to be) a
On Sat, Nov 10, 2012 at 10:22:52PM -0800, Peter Wemm wrote:
> We've had kern.ipc.nmbclusters for years. It is simple to understand,
> easy to predict the outcome of a change, is runtime adjustable, is a
> *cap* and not a reservation (like it used to be) and does not require
> a reboot like maxuser
On Sat, Nov 10, 2012 at 11:32 AM, Bruce Evans wrote:
> On Sat, 10 Nov 2012, Peter Wemm wrote:
>
>> On Sat, Nov 10, 2012 at 9:24 AM, Ian Lepore
>> wrote:
>>>
>>> On Sat, 2012-11-10 at 08:38 -0800, Alfred Perlstein wrote:
It probably could be added, but then a bunch of other people would
On Sat, Nov 10, 2012 at 11:18 AM, Andre Oppermann wrote:
> On 10.11.2012 19:04, Peter Wemm wrote:
>>
>> On Sat, Nov 10, 2012 at 9:48 AM, Eitan Adler wrote:
>>>
>>> On 10 November 2012 12:45, Peter Wemm wrote:
On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
>
> On 10 Novemb
On Nov 10, 2012, at 3:04 PM, Andre Oppermann wrote:
> On 10.11.2012 23:24, Alfred Perlstein wrote:
>> On 11/10/12 11:18 AM, Andre Oppermann wrote:
>>> On 10.11.2012 19:04, Peter Wemm wrote:
This is complicated but we need a simple user visible view of it. It
really needs to be somethin
On 10.11.2012 23:24, Alfred Perlstein wrote:
On 11/10/12 11:18 AM, Andre Oppermann wrote:
On 10.11.2012 19:04, Peter Wemm wrote:
This is complicated but we need a simple user visible view of it. It
really needs to be something like "nmbclusters defaults to 6% of
physical ram, with machine depe
On 11/10/12 9:24 AM, Ian Lepore wrote:
On Sat, 2012-11-10 at 08:38 -0800, Alfred Perlstein wrote:
On 11/10/12 8:25 AM, Eitan Adler wrote:
On 10 November 2012 11:19, Alfred Perlstein wrote:
Please consult the svn log for this file, it's relatively clear
just in the
commit logs/comments. Gre
On 11/10/12 11:18 AM, Andre Oppermann wrote:
On 10.11.2012 19:04, Peter Wemm wrote:
This is complicated but we need a simple user visible view of it. It
really needs to be something like "nmbclusters defaults to 6% of
physical ram, with machine dependent limits". The MD limits are bad
enough,
On Sat, 10 Nov 2012, Peter Wemm wrote:
On Sat, Nov 10, 2012 at 9:24 AM, Ian Lepore
wrote:
On Sat, 2012-11-10 at 08:38 -0800, Alfred Perlstein wrote:
It probably could be added, but then a bunch of other people would
complain about the comment being too wordy or "not in English".
The fact th
On 10.11.2012 19:04, Peter Wemm wrote:
On Sat, Nov 10, 2012 at 9:48 AM, Eitan Adler wrote:
On 10 November 2012 12:45, Peter Wemm wrote:
On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
On 10 November 2012 12:04, Alfred Perlstein wrote:
Sure, if you'd like you can help me craft that com
On Sat, 10 Nov 2012, Eitan Adler wrote:
On 10 November 2012 12:04, Alfred Perlstein wrote:
Sure, if you'd like you can help me craft that comment now?
I think this is short and clear:
===
Limit the amount of kernel address space used to a fixed cap.
384 is an arbitrarily chosen value that le
On Sat, Nov 10, 2012 at 9:51 AM, Garrett Cooper wrote:
> On Sat, Nov 10, 2012 at 9:45 AM, Peter Wemm wrote:
>>
>> On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
>> > On 10 November 2012 12:04, Alfred Perlstein wrote:
>> >> Sure, if you'd like you can help me craft that comment now?
>> >
>>
On Sat, Nov 10, 2012 at 9:48 AM, Eitan Adler wrote:
> On 10 November 2012 12:45, Peter Wemm wrote:
>> On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
>>> On 10 November 2012 12:04, Alfred Perlstein wrote:
Sure, if you'd like you can help me craft that comment now?
>>>
>>> I think this
On Sat, Nov 10, 2012 at 9:45 AM, Peter Wemm wrote:
> On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
> > On 10 November 2012 12:04, Alfred Perlstein wrote:
> >> Sure, if you'd like you can help me craft that comment now?
> >
> > I think this is short and clear:
> > ===
> > Limit the amount
On Sat, Nov 10, 2012 at 9:43 AM, Peter Wemm wrote:
> /* pick smaller of kva pages or physical pages */
> if ((physpages / 16) < (kvapages / 16))
> nmbclusters = physpages / 16;
> else
> nmbclusters = kvapages / 16;
(note: not actual numbers.. kva pages doesn't exist and there's a
pages vs cluste
On 10 November 2012 12:45, Peter Wemm wrote:
> On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
>> On 10 November 2012 12:04, Alfred Perlstein wrote:
>>> Sure, if you'd like you can help me craft that comment now?
>>
>> I think this is short and clear:
>> ===
>> Limit the amount of kernel add
On Sat, Nov 10, 2012 at 9:33 AM, Eitan Adler wrote:
> On 10 November 2012 12:04, Alfred Perlstein wrote:
>> Sure, if you'd like you can help me craft that comment now?
>
> I think this is short and clear:
> ===
> Limit the amount of kernel address space used to a fixed cap.
> 384 is an arbitraril
On Sat, Nov 10, 2012 at 9:24 AM, Ian Lepore
wrote:
> On Sat, 2012-11-10 at 08:38 -0800, Alfred Perlstein wrote:
>> On 11/10/12 8:25 AM, Eitan Adler wrote:
>> > On 10 November 2012 11:19, Alfred Perlstein wrote:
>> >> Please consult the svn log for this file, it's relatively clear
>> just in the
>
On 10 November 2012 12:04, Alfred Perlstein wrote:
> Sure, if you'd like you can help me craft that comment now?
I think this is short and clear:
===
Limit the amount of kernel address space used to a fixed cap.
384 is an arbitrarily chosen value that leaves 270 MB of KVA available
of the 2 MB to
On Sat, 2012-11-10 at 08:38 -0800, Alfred Perlstein wrote:
> On 11/10/12 8:25 AM, Eitan Adler wrote:
> > On 10 November 2012 11:19, Alfred Perlstein wrote:
> >> Please consult the svn log for this file, it's relatively clear
> just in the
> >> commit logs/comments. Grep for 384/512 and look aroun
On 11/10/12 8:48 AM, Eitan Adler wrote:
On 10 November 2012 11:44, Alfred Perlstein wrote:
On 11/10/12 8:38 AM, Alfred Perlstein wrote:
On 11/10/12 8:25 AM, Eitan Adler wrote:
On 10 November 2012 11:19, Alfred Perlstein wrote:
Please consult the svn log for this file, it's relatively clear
On 10 November 2012 11:44, Alfred Perlstein wrote:
> On 11/10/12 8:38 AM, Alfred Perlstein wrote:
>>
>> On 11/10/12 8:25 AM, Eitan Adler wrote:
>>>
>>> On 10 November 2012 11:19, Alfred Perlstein wrote:
Please consult the svn log for this file, it's relatively clear just in
the
>>>
On 11/10/12 8:38 AM, Alfred Perlstein wrote:
On 11/10/12 8:25 AM, Eitan Adler wrote:
On 10 November 2012 11:19, Alfred Perlstein wrote:
Please consult the svn log for this file, it's relatively clear just
in the
commit logs/comments. Grep for 384/512 and look around.
Can this reasoning be ad
On 11/10/12 8:25 AM, Eitan Adler wrote:
On 10 November 2012 11:19, Alfred Perlstein wrote:
Please consult the svn log for this file, it's relatively clear just in the
commit logs/comments. Grep for 384/512 and look around.
Can this reasoning be added as a comment? I did grep for 384 in the lo
On 10 November 2012 11:19, Alfred Perlstein wrote:
> Please consult the svn log for this file, it's relatively clear just in the
> commit logs/comments. Grep for 384/512 and look around.
Can this reasoning be added as a comment? I did grep for 384 in the log, but
a) I didn't find the answer
b) o
On 11/10/12 2:50 AM, Andriy Gapon wrote:
on 10/11/2012 04:56 Alfred Perlstein said the following:
Sure, this is magic for i386 PAE machines. 384 maxusers was pretty much the
highest you wanted auto-tuned SAFELY for 32bit KVA on i386.
So 384 is i386 sans 'i' and minus two? :-)
Sorry, I still co
on 10/11/2012 04:56 Alfred Perlstein said the following:
> Sure, this is magic for i386 PAE machines. 384 maxusers was pretty much the
> highest you wanted auto-tuned SAFELY for 32bit KVA on i386.
So 384 is i386 sans 'i' and minus two? :-)
Sorry, I still couldn't find an explanation of 384 in you
On 11/9/12 6:34 PM, Eitan Adler wrote:
On 9 November 2012 21:08, Alfred Perlstein wrote:
Modified: head/sys/kern/subr_param.c
+#ifdef VM_MAX_AUTOTUNE_MAXUSERS
+if (maxusers > VM_MAX_AUTOTUNE_MAXUSERS)
+maxusers = VM_MAX_AUTOTUNE_MAXUSERS;
+#endif
+
On 9 November 2012 21:08, Alfred Perlstein wrote:
> Modified: head/sys/kern/subr_param.c
> +#ifdef VM_MAX_AUTOTUNE_MAXUSERS
> +if (maxusers > VM_MAX_AUTOTUNE_MAXUSERS)
> +maxusers = VM_MAX_AUTOTUNE_MAXUSERS;
> +#endif
> +/*
> +
Author: alfred
Date: Sat Nov 10 02:08:40 2012
New Revision: 242847
URL: http://svnweb.freebsd.org/changeset/base/242847
Log:
Allow maxusers to scale on machines with large address space.
Some hooks are added to clamp down maxusers and nmbclusters for
small address space systems.
VM_M
40 matches
Mail list logo
