On Jan 5, 2013, at 12:47 PM, Adrian Chadd wrote:
> On 5 January 2013 07:38, Hakisho Nukama wrote:
>> FreeBSD (PCBSD) is slower compared to Linux and kFreeBSD in this
>> benchmark of HIMENO:
>> http://openbenchmarking.org/prospect/1202215-BY-FREEBSD9683/88ac7a01c6cb355d7e7603224b2ee1e5a4cb881d
>>
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein wrote:
> So the other day in an effort to debug a memory leak I decided to take a look
> at malloc+utrace(2) and decided to make a tool to debug where leaks are
> coming from.
>
> A few hours later I have:
> 1) a new version of utrace(2) (utrace2(2)
Maxim Sobolev wrote:
Jason Evans wrote:
Maxim Sobolev wrote:
I am trying to figure out why java fails to start with 1024MB of heap
on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are
set to 2GB.
Some memory (1GiB?) is reserved for kernel address space, and you
reserved
Maxim Sobolev wrote:
I am trying to figure out why java fails to start with 1024MB of heap on
i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are set
to 2GB.
Some memory (1GiB?) is reserved for kernel address space, and you
reserved 2GiB for DSS. That leaves less than 1GiB ava
Fabian Keil wrote:
Rémi Denis-Courmont, one of the vlc developers, pointed out
that passing a zero size to posix_memalign() should actually
work, though:
| In principle, while useless, there is no reason why allocating an empty
| picture should not be possible. posix_memalign() does support zer
Robert Watson wrote:
On Fri, 27 Mar 2009, Poul-Henning Kamp wrote:
In message ,
Robert Wats on writes:
In which case user application threads will need to know their CPU [...]
Didn't jemalloc solve that problem once already ?
I think jemalloc implements thread-affinity for arenas rather t
Brian Fundakowski Feldman wrote:
> Could you, and anyone else who would care to, check this out? It's
a regression
fix but it also makes the code a little bit clearer. Thanks!
Index: lib/libc/stdlib/malloc.c
Why does malloc need to change for this? Unless there's a really good
reason, I
Stephen Montgomery-Smith wrote:
I notice that if you use "malloc" from within a signal handler on
FreeBSD-6.x, that you can potentially trigger a "recursive call" error.
But this seems to have changed in FreeBSD-7.x.
The malloc implementation is completely new in FreeBSD 7, so not all of
the
Andrew MacIntyre wrote:
However my reading of the updated man page suggests that the malloc
options string should be "Dm" or "m" to turn off mmap() and only use
sbrk() - could you clarify why "d"?
Whoops, I meant "m", not "d".
Jason
___
freebsd-hacke
Andrew MacIntyre wrote:
In investigating a Python 2.6rc1 regression test failure on FreeBSD
7.0/amd64, as far as I can tell, malloc() does not return NULL when
available memory (including swap) is exhausted - the process just gets
KILLed.
Using ulimit -v to set a virtual memory use limit below t
Markus Hoenicka wrote:
I've been redirected by Giorgos Keramidas to this list after reporting
a problem on the freebsd-questions list. I'd greatly appreciate if you
could have a look at the following problem. Apparently programs are
doomed to segfault on FreeBSD if dlopen()ed modules install exit
Pietro Cerutti wrote:
uname -r
8.0-CURRENT
Mplayer always crashes quitting .flv video (either by pressing 'q' or
because the video is over).
The error is:
Assertion failed: (diff == regind * size), function
arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 1714.
Removing the
Ed Schouten wrote:
For some reason, I want to understand how the queueing of blocked
threads in the kernel works when waiting for a lock, which is if I
understand correctly done by the turnstiles and sleepqueues. I'm the
proud owner of The Design and Implementation of the FreeBSD Operating
System
李鑫 (LI Xin) wrote:
在 2006-08-15二的 02:38 +0300，Vladimir Kushnir写道：
On -CURENT amd64 (Athlon64 3000+, 512k L2 cache):
With jemalloc (without MY_MALLOS):
~/fdtd> /usr/bin/time ./fdtd.FreeBSD 500 500 1000
...
116.34 real 113.69 user 0.00 sys
With MY_MALLOC:
~/fdtd> /usr/bin/time
[EMAIL PROTECTED] wrote:
IMHO, and purely as constructive criticism, Jason's article would've been much
more interesting if he had tested ptmalloc (in the ports tree) and we had had
libumem.
Yes, that would have been nice, but when I tried to use ptmalloc, it
failed to work correctly. I don't
bert hubert wrote:
Thanks Jason, this has helped narrow down the problem significantly. From
this I understand that to work around this problem, I have some options:
1) tweak my code to not allocate such a large amount of small objects
2) move away from malloc/free based c++ allocators
3) recomp
bert hubert wrote:
Dear FreeBSD hackers,
I'm working on improving the PowerDNS recursor for a big FreeBSD-loving
internet provider in The Netherlands and I am hitting some snags. I also
hope this is the appropriate list to share my concerns.
Pruning the cache is very very slow on the providers
John-Mark Gurney wrote:
That's why I started work on rewriting a allocated based upon the
paper so that it'd have a BSD license... I haven't worked on it much,
and now that jemalloc is here, who knows...
Are you referring to the 2001 Usenix paper by Bonwick and Adams? That
paper is a very in
On Jan 31, 2006, at 1:06 AM, Sam Lawrance wrote:
ElectricFence is failing during its self test on i386 7-current:
Testing Electric Fence.
After the last test, it should print that the test has PASSED.
EF_PROTECT_BELOW= && EF_PROTECT_FREE= && EF_ALIGNMENT= && ./eftest
Segmentation fault (core dum
On Jan 26, 2006, at 12:55 AM, Jose Marcio Martins da Cruz wrote:
Can you point me a good doc about threads, signals, and such kind
of things in
FreeBSD context ?
David Butenhof's book, "Programming with POSIX Threads", includes a
good discussion of signals in the context of pthreads. How t
On Fri, Feb 08, 2002 at 07:46:34AM +0200, Maxim Sobolev wrote:
> Hi,
>
> When working on updating port of Ximian Evolution to the latest released
> version I have stuck to the problem - the new version of application
> just hanged on startup on my 5-CURRENT box. After lot of digging and
> debuggi
The typical solution is to create a pipe, and write a byte to it in order
to wake up the manager thread.
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, Oct 05, 2001 at 02:19:58PM +, E.B. Dreger wrote:
>
> However, there's a rather ominous and non-descriptive warning
> present: "There are numerous stability issues in the current aio
> code that make it unsuitable for inclusion on shell boxes." Can
> anyone please elaborate? Is this
On Wed, Aug 08, 2001 at 11:17:38AM -0700, Julian Elischer wrote:
> not from me, though you might say why you want this..
I think the reason was in the Subject line:
Subject: [PATCH] Change lockmgr() to not recursively panic
Jason
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "uns
A lot of good progress has been made on the SMP project in the past couple
of weeks. We are on the verge of being able to move portions of the kernel
out of under the Giant lock, which will be the first improvement in
performance due to our work, following a long string of developments over
the p
On Mon, Nov 06, 2000 at 01:33:21AM +1000, [EMAIL PROTECTED] wrote:
> Hi,
>
> I have a program compiled with -pthread and I'm trying to use gdb to debug
> it. I run the program in one window and then try to attach to it from
> another. I have put a sleep 10 in the program so I can catch it before
On Mon, Apr 24, 2000 at 04:44:05PM -0500, Richard Seaman, Jr. wrote:
> On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote:
> > FreeBSD's threads should perform adequately given the design of your program
> > and the hardware you listed. Actually trying it on t
On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote:
> I am currently porting a multithreaded TCP server from NT (yech!) to
> UNIX using pthreads. The server has a fairly straightforward design --
> it opens a thread for each connection, and each thread spends most of
> its life blocked
ld find
no program that actually does this, so I wrote one.
The program is attached (yes, it needs a man page if it is to be imported),
but my question is whether it belongs in the source tree, and if so, where?
Thanks,
Jason
/*
* Copyright (C) 2000 Jason Evans <[EMAIL PROTECTED]>.
* All
On Sat, Feb 05, 2000 at 03:16:28PM -0800, Alfred Perlstein wrote:
> Ugh, I should have brought this up before the code freeze but...
>
> Maybe we could make 4.0 the transition point for adding locking
> structures to FILE and DIR structures instead of the hackish
> way it's done now (maintaining
On Sun, Jan 23, 2000 at 11:36:08AM -0500, Mikhail Teterin wrote:
> David Schwartz once stated:
>
> => =FreeBSD:
> => ==> => If timeout is a non-nil pointer, it specifies a maximum
> => ==> => interval to wait for the selection to complete.
>
> = While the pthreads case is clearly a bug,
On Tue, Jan 18, 2000 at 04:36:43AM +0200, Iani Brankov wrote:
> Daniel Eischen wrote:
> >
> > > Hi,
> > >
> > > after making world of a CURRENT cvsupped yesterday, one of my
> > > applications stopped working because of a Segmentation fault.
> > >
> > > The C procedure where the problem pops has
On Sun, Jan 16, 2000 at 11:45:12PM -0700, Wes Peters wrote:
> Jason Evans wrote:
> >
> > You don't mention how long you run the program for, so I'm assuming that
> > the runtime must be quite short for you to be seeing the results that
> > concerned you.
On Sun, Jan 16, 2000 at 10:50:45PM -0500, Alexander Litvin wrote:
> I've a simple sample program (see at the bottom). It creates 10
> threads with start function start_my_thread(), and then runs the
> same function in main(). So, we have 11 threads doing the same job.
>
> Function start_my_thread
On Sun, Jan 16, 2000 at 10:18:56PM -0700, Wes Peters wrote:
> Michael Bacarella wrote:
> >
> > > Program, when killed with SIGINT, prints all counters and exits.
> > >
> > > Now, as I understand, userspace threads in FreeBSD are preemptive.
> > > So, though my 11 threads are all computational and
On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote:
> > Consider as an example that open() is a thread cancellation point according
> > to POSIX. If libpthread overrides the libc open() with its own version of
> > open(), then by extension, every function that calls open() can potenti
On Thu, Jan 13, 2000 at 10:27:23AM +0100, ROGIER MULHUIJZEN wrote:
> I'm forwarding this from the GTK development list. According to Owen
> their is something wrong with the threads implementation
>
> Is that true? or is it a "It's not the way Linux works, so it must be
> wrong"-pigheadedness
[CCed to -hackers since this may be of general interest.]
On Wed, Jan 12, 2000 at 11:21:41PM -0800, David O'Brien wrote:
> I'm still a little puzzled why every call to open got changed to
> _libc_open rather than do the magic w/in open().
Consider as an example that open() is a thread cancellati
On Tue, Jan 11, 2000 at 09:56:58PM -0800, Matthew Dillon wrote:
>
> :> fork1() in the kernel]. rfork(RFMEM) means that the processes share all
> :> memory - current AND FUTURE. You could use minherit() before fork() to
> :> share current memory, but not future memory.
> :
> :BTW, concerning rfo
On Tue, Jan 11, 2000 at 03:23:13PM -0800, Scott Hess wrote:
> Matthew Dillon <[EMAIL PROTECTED]> wrote:
> > A better solution may be to shift to FreeBSD4.0 (when it's released -
> > wait for it to become good and stable), and then use the native
> > linuxthreads port (/usr/ports/devel/
On Tue, Jan 11, 2000 at 12:49:32PM -0600, Richard Seaman, Jr. wrote:
> On Tue, Jan 11, 2000 at 10:35:27AM -0800, Jason Evans wrote:
> > The naming
> > approach I'm taking is:
> >
> > fwrite() <-- Alternate entry point that is used externally unless
>
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> It's my impression that glibc uses a three (four?) tiered naming
> convention. The "pure" syscall (in our case, eg. _write()). Then
> there is the version used internally in glibc (eg. _libc_write().
> And finally, the versio
On Mon, Jan 10, 2000 at 10:48:29PM +0100, Arjan de Vet wrote:
> Christopher Sedore wrote:
>
> >On Thu, 6 Jan 2000, Arjan de Vet wrote:
> >
> >> Jordan K. Hubbard wrote:
> >>
> >> >This is very interesting data and I was just wondering about the
> >> >actual state of functionality in our AIO code
On Tue, Dec 28, 1999 at 06:01:53PM -0600, Richard Seaman, Jr. wrote:
> The new version of linuxthreads now seems extend cancellation points
> into libc. However, it does so in a manner that threads can get
> cancelled within libc with libc holding internal locks, resulting
> in deadlock.
>
> I t
On Mon, Dec 20, 1999 at 08:24:28PM -0500, Chris Sedore wrote:
> On Mon, 20 Dec 1999, Jason Evans wrote:
> > I disagree with your assessment that scalability of one thread per
> > connection is proportional to the quality of the threads implementation.
> > An ideal thread
On Sun, Dec 19, 1999 at 03:01:41PM -0500, Chris Sedore wrote:
>
>
> On Sat, 18 Dec 1999, Alfred Perlstein wrote:
>
> > On Sat, 18 Dec 1999, Kevin Day wrote:
> >
> > > > The _clean_ way of doing it would be to write your multi-user server using
> > > > threads, and to assign one thread to each
On Thu, Dec 09, 1999 at 06:42:56AM -0600, Richard Seaman, Jr. wrote:
> On Thu, Dec 09, 1999 at 12:35:17AM -0800, Jason Evans wrote:
>
> The problem with cancellation points, libc and linuxthreads has been
> that you need to wade through libc and replace instances of, for
> exampl
I've got a port of the most recent LinuxThreads (glibc-linuxthreads-2.1.2)
running, but ran into a couple of minor problems integrating with our libc.
LinuxThreads redefines a number of functions in order to make them either
support thread cancellation or work correctly.
The following functions n
I'm porting the most recent released version of LinuxThreads
(glibc-linuxthreads-2.1.2), and ran into a bit of a problem with regard to
longjmp() and siglongjmp(). LinuxThreads wraps these functions so that
they work correctly in the presence of cleanup handlers. However, this
doesn't appear to
ying on the -pthread linker
magic. This is high on Daniel Eischen's wish list, so maybe he already
has something in the works. =)
If you know of other outstanding issues that have a prayer of being
addressed before 4.0 ships, please speak up.
Jason
Jason Evans <[EMAIL PROTECTED]>
h
50 matches
Mail list logo
