Hi All,
Can anyone think of any quick pointers as to why some code originally
written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes up
a *lot* more memory when running?
The code involved is a sendmail Milter, and a TCP server type program (that
runs up a large number of th
- Original Message -
From: "Karl Pielorz"
To:
Sent: Tuesday, October 30, 2012 11:12 AM
Subject: Threaded 6.4 code compiled under 9.0 uses a lot more memory?..
Hi All,
Can anyone think of any quick pointers as to why some code originally
written under 6.4 amd64 - when re-compiled
Hi,
On Tue, 30 Oct 2012 11:12:22 +
Karl Pielorz wrote:
> Can anyone think of any quick pointers as to why some code originally
> written under 6.4 amd64 - when re-compiled under 9.0-stable amd64
> takes up a *lot* more memory when running?
>
is it still the same compiler?
> As an example
--On 30 October 2012 11:21 + Steven Hartland
wrote:
They've not been running longing enough yet to see if anything is
'leaking' (i.e. if size/res continues to go up). Just thought I'd ask
if there's a simple/possible explanation for this - and if it's
something I need to worry about.
Karl Pielorz wrote:
> Can anyone think of any quick pointers as to why some code originally
> written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes
> up a *lot* more memory when running?
6.4 comes with phkmalloc while 9.0 uses jemalloc. Maybe you are
allocating memory in a way
If this is only difference between gcc34 v gcc42 it's quite spectacular...
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/Threaded-6-4-code-compiled-under-9-0-uses-a-lot-more-memory-tp5756466p5756476.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.
_
--On 30 October 2012 18:27 +0700 Erich Dollansky
wrote:
is it still the same compiler?
Depends how you mean 'the same' - on the 6.4 system it shows:
cc (GCC) 3.4.6 [FreeBSD] 20060305
And, on the 9.0-S it shows:
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
So 'same' - but different ve
--On 30 October 2012 22:59 +1100 Jan Mikkelsen
wrote:
-O2 -pthread -lc_r
They're now compiled under 9.0-S with just:
-O2 -pthread
libc_r is a user mode implementation of pthreads, so there is one actual
kernel thread with a stack. You now have ~700 kernel threads on startup.
Per-thread
Hi,
On 30/10/2012, at 10:12 PM, Karl Pielorz wrote:
>
> Hi All,
>
> Can anyone think of any quick pointers as to why some code originally written
> under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes up a *lot*
> more memory when running?
>
> The code involved is a sendmail Mil
Hi,
On Tue, 30 Oct 2012 11:59:46 +
Karl Pielorz wrote:
>
>
> --On 30 October 2012 18:27 +0700 Erich Dollansky
> wrote:
>
> > is it still the same compiler?
>
> Depends how you mean 'the same' - on the 6.4 system it shows:
>
>cc (GCC) 3.4.6 [FreeBSD] 20060305
>
> And, on the 9.0-S
On Tue, 2012-10-30 at 13:46 +0100, Fabian Keil wrote:
> Karl Pielorz wrote:
>
> > Can anyone think of any quick pointers as to why some code originally
> > written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes
> > up a *lot* more memory when running?
>
> 6.4 comes with phkmall
On 30/10/2012 15:47, Ian Lepore wrote:
> On Tue, 2012-10-30 at 13:46 +0100, Fabian Keil wrote:
>> Karl Pielorz wrote:
>>
>>> Can anyone think of any quick pointers as to why some code originally
>>> written under 6.4 amd64 - when re-compiled under 9.0-stable amd64 takes
>>> up a *lot* more memory
hi,
as soon as I 'initialize' a virtual disk via gpart, even if nothing
is mounted, the pxeboot adds around 60s delay to show the boot menu,
- I don't know if the delay is in boot or pxeboot.
if I destroy the geom, the the boot menu appears inmediately.
any insight?
danny
__
--On 30 October 2012 19:43 +0700 Erich Dollansky
wrote:
Depends how you mean 'the same' - on the 6.4 system it shows:
cc (GCC) 3.4.6 [FreeBSD] 20060305
And, on the 9.0-S it shows:
cc (GCC) 4.2.1 20070831 patched [FreeBSD]
So 'same' - but different versions.
did you check the def
Some suggestions here, jemalloc, kernel threads are good ones.
Another issue may just be some change for default thread stack size.
This would explain why the RESIDENT set is the same, but the VIRTUAL grew.
-Alfred
On 10/30/12 9:56 AM, Karl Pielorz wrote:
--On 30 October 2012 19:43 +0700
On Tue, Oct 30, 2012 at 10:48:03AM -0700, Alfred Perlstein wrote:
> Some suggestions here, jemalloc, kernel threads are good ones.
>
> Another issue may just be some change for default thread stack size.
> This would explain why the RESIDENT set is the same, but the VIRTUAL grew.
I suggest to ta
16 matches
Mail list logo
