On 14.01.2013 16:00, Andre Oppermann wrote:
On 13.01.2013 11:10, Alan Cox wrote:
3. The function vm_ksubmap_init() has a dependency on the global
variable maxpipekva. vm_ksubmap_init() is executed under SI_SUB_CPU,
which comes after SI_SUB_KMEM.
Am I missing anything?
I'm attaching a patch th
On Mon, 14 Jan 2013, John Baldwin wrote:
On Monday, January 14, 2013 10:51:27 am Alexander Motin wrote:
As I've actually written, there are two different things:
ncallout -- number of preallocated callout structures for purposes of
timeout() calls. That is a legacy API that is probably not ver
On 1/14/13 12:55 PM, John Baldwin wrote:
On Monday, January 14, 2013 10:51:27 am Alexander Motin wrote:
As I've actually written, there are two different things:
ncallout -- number of preallocated callout structures for purposes of
timeout() calls. That is a legacy API that is probably not ver
On Monday, January 14, 2013 10:51:27 am Alexander Motin wrote:
> As I've actually written, there are two different things:
> ncallout -- number of preallocated callout structures for purposes of
> timeout() calls. That is a legacy API that is probably not very much
> used now, so that value don't
On 14.01.2013 18:05, Andre Oppermann wrote:
> On 14.01.2013 16:51, Alexander Motin wrote:
>> As I've actually written, there are two different things:
>> ncallout -- number of preallocated callout structures for purposes of
>> timeout() calls. That is a legacy API that is probably not very much
>
On 1/14/13 11:05 AM, Andre Oppermann wrote:
Can timeout() be emulated on top of another API so we can do away with
it?
yes, this is what callout(9) is for.
there are a few consumers left (see the email I just sent out).
those consumers would just have to allocate their own callout
handle/s
On 14.01.2013 16:51, Alexander Motin wrote:
On 14.01.2013 17:09, Andre Oppermann wrote:
On 13.01.2013 19:06, Alfred Perlstein wrote:
On 1/12/13 10:32 PM, Adrian Chadd wrote:
On 12 January 2013 11:45, Alfred Perlstein wrote:
I'm not sure if regressing to the waterfall method of development i
On 14.01.2013 17:09, Andre Oppermann wrote:
> On 13.01.2013 19:06, Alfred Perlstein wrote:
>> On 1/12/13 10:32 PM, Adrian Chadd wrote:
>>> On 12 January 2013 11:45, Alfred Perlstein wrote:
>>>
I'm not sure if regressing to the waterfall method of development is
a good
idea at this p
On 1/14/13 10:09 AM, Andre Oppermann wrote:
On 13.01.2013 19:06, Alfred Perlstein wrote:
On 1/12/13 10:32 PM, Adrian Chadd wrote:
On 12 January 2013 11:45, Alfred Perlstein wrote:
I'm not sure if regressing to the waterfall method of development
is a good
idea at this point.
I see a light
On 13.01.2013 19:06, Alfred Perlstein wrote:
On 1/12/13 10:32 PM, Adrian Chadd wrote:
On 12 January 2013 11:45, Alfred Perlstein wrote:
I'm not sure if regressing to the waterfall method of development is a good
idea at this point.
I see a light at the end of the tunnel and we to continue to
On 13.01.2013 11:10, Alan Cox wrote:
On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
On 12/18/2012 1:59 AM, Alan Cox wrote:
On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
That makes sense. Howe
.. I think the "right" solution is to still review what things rely on
maxusers/maxfiles/etc and figure out which make sense to scale off of
a global variable, and which don't.
Adrian
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/
On 1/12/13 10:32 PM, Adrian Chadd wrote:
On 12 January 2013 11:45, Alfred Perlstein wrote:
I'm not sure if regressing to the waterfall method of development is a good
idea at this point.
I see a light at the end of the tunnel and we to continue to just handle
these minor corner cases as we pr
On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
> On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
>> On 12/18/2012 1:59 AM, Alan Cox wrote:
>>> On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
> On 12/08/2012 14:32, Andre Oppermann wrote
On 12 January 2013 11:45, Alfred Perlstein wrote:
> I'm not sure if regressing to the waterfall method of development is a good
> idea at this point.
>
> I see a light at the end of the tunnel and we to continue to just handle
> these minor corner cases as we progress.
>
> If we move to a model w
On 1/12/13 11:56 AM, Adrian Chadd wrote:
Hi,
I think this outlines a larger scale problem here, which is that way,
way too many things are relying on maxfiles here and it wasn't
properly reviewed or thought out before it made it into the tree.
So, can we either:
* review _all_ the places maxfi
On 01/12/2013 10:56, Adrian Chadd wrote:
> Hi,
>
> I think this outlines a larger scale problem here, which is that way,
> way too many things are relying on maxfiles here and it wasn't
> properly reviewed or thought out before it made it into the tree.
>
> So, can we either:
>
> * review _all_ the
On 01/12/2013 09:46, Jayachandran C. wrote:
> On Fri, Jan 11, 2013 at 11:16 PM, Alan Cox wrote:
>> On 01/11/2013 05:38, Jayachandran C. wrote:
> [...]
>>> I see an issue with commit on MIPS XLP platform as well.
>>>
>>> With 16 GB physical memory, the ncallout is calculated to be 538881
>>> (since
Hi,
I think this outlines a larger scale problem here, which is that way,
way too many things are relying on maxfiles here and it wasn't
properly reviewed or thought out before it made it into the tree.
So, can we either:
* review _all_ the places maxfiles is being used, and finally fix those;
*
On Fri, Jan 11, 2013 at 11:16 PM, Alan Cox wrote:
> On 01/11/2013 05:38, Jayachandran C. wrote:
[...]
>> I see an issue with commit on MIPS XLP platform as well.
>>
>> With 16 GB physical memory, the ncallout is calculated to be 538881
>> (since it is based on maxfiles - which is now based on the
On 01/11/2013 05:38, Jayachandran C. wrote:
> On Tue, Jan 8, 2013 at 3:12 AM, Andre Oppermann wrote:
>> On 07.01.2013 20:32, Alan Cox wrote:
>>> On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
> On 12/18/2012 1:59 AM, Alan Cox wrote:
>>>
On Tue, Jan 8, 2013 at 3:12 AM, Andre Oppermann wrote:
> On 07.01.2013 20:32, Alan Cox wrote:
>>
>> On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
>>>
>>> On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
On 12/18/2012 1:59 AM, Alan Cox wrote:
>
> On 12/17/2012 23:40, Oleksand
On 07.01.2013 20:32, Alan Cox wrote:
On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
On 12/18/2012 1:59 AM, Alan Cox wrote:
On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
On 12/08/2012 14:32, A
On 01/07/2013 12:47, Oleksandr Tymoshenko wrote:
> On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
>> On 12/18/2012 1:59 AM, Alan Cox wrote:
>>> On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
> On 12/08/2012 14:32, Andre Oppermann wrote
On 12/27/2012 6:46 PM, Oleksandr Tymoshenko wrote:
On 12/18/2012 1:59 AM, Alan Cox wrote:
On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
On 12/08/2012 14:32, Andre Oppermann wrote:
.. skipped ..
The trouble seems to come from NSFBUFS which is (
On 12/18/2012 1:59 AM, Alan Cox wrote:
On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
On 12/08/2012 14:32, Andre Oppermann wrote:
.. skipped ..
The trouble seems to come from NSFBUFS which is (512 + maxusers * 16)
resulting in a kernel map of (5
On 12/17/2012 23:40, Oleksandr Tymoshenko wrote:
> On 2012-12-08, at 1:21 PM, Alan Cox wrote:
>
>> On 12/08/2012 14:32, Andre Oppermann wrote:
> .. skipped ..
>
>>> The trouble seems to come from NSFBUFS which is (512 + maxusers * 16)
>>> resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE =
On 18.12.2012 06:40, Oleksandr Tymoshenko wrote:
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
On 12/08/2012 14:32, Andre Oppermann wrote:
.. skipped ..
The trouble seems to come from NSFBUFS which is (512 + maxusers * 16)
resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE = 27MB.
On 2012-12-08, at 1:21 PM, Alan Cox wrote:
> On 12/08/2012 14:32, Andre Oppermann wrote:
>>>
.. skipped ..
>>
>> The trouble seems to come from NSFBUFS which is (512 + maxusers * 16)
>> resulting in a kernel map of (512 + 400 * 16) * PAGE_SIZE = 27MB. This
>> seem to be pushing it with the
On 12/08/2012 14:32, Andre Oppermann wrote:
> On 07.12.2012 23:17, Oleksandr Tymoshenko wrote:
>> On 12/7/2012 1:44 PM, Andre Oppermann wrote:
>>> On 07.12.2012 22:05, Oleksandr Tymoshenko wrote:
On 12/7/2012 1:53 AM, Andre Oppermann wrote:
> On 07.12.2012 10:36, Oleksandr Tymoshenko wrote
On 07.12.2012 23:17, Oleksandr Tymoshenko wrote:
On 12/7/2012 1:44 PM, Andre Oppermann wrote:
On 07.12.2012 22:05, Oleksandr Tymoshenko wrote:
On 12/7/2012 1:53 AM, Andre Oppermann wrote:
On 07.12.2012 10:36, Oleksandr Tymoshenko wrote:
On 2012-11-27, at 1:19 PM, Andre Oppermann wrote:
Au
On 12/7/2012 1:44 PM, Andre Oppermann wrote:
On 07.12.2012 22:05, Oleksandr Tymoshenko wrote:
On 12/7/2012 1:53 AM, Andre Oppermann wrote:
On 07.12.2012 10:36, Oleksandr Tymoshenko wrote:
On 2012-11-27, at 1:19 PM, Andre Oppermann wrote:
Author: andre
Date: Tue Nov 27 21:19:58 2012
New Rev
On 07.12.2012 22:05, Oleksandr Tymoshenko wrote:
On 12/7/2012 1:53 AM, Andre Oppermann wrote:
On 07.12.2012 10:36, Oleksandr Tymoshenko wrote:
On 2012-11-27, at 1:19 PM, Andre Oppermann wrote:
Author: andre
Date: Tue Nov 27 21:19:58 2012
New Revision: 243631
URL: http://svnweb.freebsd.org/c
On 12/7/2012 1:53 AM, Andre Oppermann wrote:
On 07.12.2012 10:36, Oleksandr Tymoshenko wrote:
On 2012-11-27, at 1:19 PM, Andre Oppermann wrote:
Author: andre
Date: Tue Nov 27 21:19:58 2012
New Revision: 243631
URL: http://svnweb.freebsd.org/changeset/base/243631
.. skipped ..
Andre,
thes
On 07.12.2012 10:36, Oleksandr Tymoshenko wrote:
On 2012-11-27, at 1:19 PM, Andre Oppermann wrote:
Author: andre
Date: Tue Nov 27 21:19:58 2012
New Revision: 243631
URL: http://svnweb.freebsd.org/changeset/base/243631
Log:
Base the mbuf related limits on the available physical memory or
On 2012-11-27, at 1:19 PM, Andre Oppermann wrote:
> Author: andre
> Date: Tue Nov 27 21:19:58 2012
> New Revision: 243631
> URL: http://svnweb.freebsd.org/changeset/base/243631
>
> Log:
> Base the mbuf related limits on the available physical memory or
> kernel memory, whichever is lower. Th
On Thu, 29 Nov 2012, Andre Oppermann wrote:
On 28.11.2012 22:45, Bruce Evans wrote:
On Wed, 28 Nov 2012, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
On 29.11.2012 00:14, Bruce Evans wrote:
On Wed, 28 Nov 2012, Andre Oppermann wrote:
On 28.11.2012 18:37, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
On 28.11.2012 22:45, Bruce Evans wrote:
On Wed, 28 Nov 2012, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
It overflows on i386 even without PAE, where
On Wed, 28 Nov 2012, Andre Oppermann wrote:
On 28.11.2012 18:37, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
Right. long == int on i386/PAE, not LP64
On 28.11.2012 18:37, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
Right. long == int on i386/PAE, not LP64. Is uint64_t the correct type
to use to catc
Can you please post some example figures for machines with 16, 32, 64 and 128MB?
As Bruce has just replied, there's concern about this tuning being
very "lots of RAM" centric, which certainly isn't the case.
I'd hate to see this swing from one extreme (not enough mbufs) to the
other extreme ..
On Wed, 28 Nov 2012, Alan Cox wrote:
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
It overflows on i386 even without PAE, where the number of bytes of
physical memory is
I'm pretty sure that the "realmem" calculation is going to overflow on
i386/PAE, where the number of bytes of physical memory is greater than
the type long can represent.
On 11/27/2012 15:19, Andre Oppermann wrote:
> Author: andre
> Date: Tue Nov 27 21:19:58 2012
> New Revision: 243631
> URL: http
44 matches
Mail list logo
