On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
FreeBSD:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
On 1/10/13 1:05 PM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
On Thu, Jan 10, 2013 at 01:29:38PM -0500, Alfred Perlstein wrote:
On 1/10/13 1:05 PM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 10:16:46AM -0500, Alfred Perlstein wrote:
On 1/10/13 2:38 AM, Konstantin Belousov wrote:
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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
On 1/10/13 1:41 AM, Alfred Perlstein wrote:
On 12/23/12 12:28 PM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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
On Thu, Jan 10, 2013 at 01:56:48AM -0500, Alfred Perlstein wrote:
Here are more convenient links that give diffs against FreeBSD and
jemalloc for the proposed changes:
FreeBSD:
https://github.com/alfredperlstein/freebsd/compare/13e7228d5b83c8fcfc63a0803a374212018f6b68~1...utrace2
Why do
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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)
On 12/23/12 9:28 AM, Jason Evans wrote:
On Dec 21, 2012, at 7:37 PM, Alfred Perlstein bri...@mu.org 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
On 21 December 2012 22:37, Alfred Perlstein bri...@mu.org wrote:
Is it time to start installing with some form of debug symbols? This would
help us also with dtrace.
I just posted a patch to add a knob to build and install standalone
debug files. My intent is that we will build releases with
On 12/22/12 8:56 AM, Ed Maste wrote:
On 21 December 2012 22:37, Alfred Perlstein bri...@mu.org wrote:
Is it time to start installing with some form of debug symbols? This would
help us also with dtrace.
I just posted a patch to add a knob to build and install standalone
debug files. My
On Thursday, March 22, 2012 3:57:11 pm Eric Saint-Etienne wrote:
If your kernel module creates a device in /dev that implements the
mmap method, then you don't need to worry about mucking around with
vm_maps and objects and whatnot. Your mmap method just needs to be
able to convert
I've refined the behaviour I observe, which isn't consistent depending
on the size one mallocates.
(see interleaved comments)
In my driver, I need to map some malloc-ed memory, obtained from
another module, into userspace.
The problem: on the smaller mallocs, as well as on some bigeer ones
On Wednesday, March 21, 2012 7:27:58 pm Eric Saint-Etienne wrote:
Hi,
From within the freeBSD kernel, not all malloc are made equal:
* malloc() smaller than KMEM_ZMAX (set to one page size) end up in
UMA SLABs, themselves laid out in powers of 2 (from 16 bytes, 32... to
4096 bytes)
By using kernel_map instead of kmem_map, vm_map_lookup() now always
return a vm_object. That's a big progress.
As expected, when this object is kmem_object, the user mapping works
fine (for smaller or larger mallocs.)
Otherwise that object doesn't match kernel_object. It's an anonymous
On Thu, Mar 22, 2012 at 10:42 AM, Eric Saint-Etienne
eric.saintetie...@gmail.com wrote:
Actually when using kernel_map, the object returned is NULL! However the
the vm_entry_t it returns seems a valid address, its 'object' field is NULL
too (that's consistent)
That's the reason why I didn't
If your kernel module creates a device in /dev that implements the
mmap method, then you don't need to worry about mucking around with
vm_maps and objects and whatnot. Your mmap method just needs to be
able to convert offsets into the device into physical memory
addresses,
Yes I'm aware of
Here is some code which fails with malloc 1 page
and sometimes succeeds with large mallocs ( 16 pages)
What's wrong?
#include sys/param.h
#include sys/proc.h
#include sys/conf.h
#include sys/module.h
#include sys/sysent.h
#include sys/kernel.h
#include sys/systm.h
#include sys/sysproto.h
sys/malloc.h has function prototypes for malloc()
kern/kern_malloc.c defines the malloc()
the malloc() definition is
void *
malloc(size, type, flags)
unsigned long size;
struct malloc_type *type;
int flags;
i understand the size and flags but what shall i
On Mon, 17 Oct 2005 21:19, kamal kc wrote:
void *
malloc(size, type, flags)
unsigned long size;
struct malloc_type *type;
int flags;
i understand the size and flags but what shall i
do with the malloc_type.
man 9 malloc
It is used to do basic sanity checking and for
Hi, Kamal
On 17.10.2005 04:49:01, kamal kc wrote:
this may be a trivial question for many of you
but i am confused in doing memory allocation in the
kernel.
sys/malloc.h has function prototypes for malloc()
kern/kern_malloc.c defines the malloc()
the malloc() definition is
void *
On Mon, 17 Oct 2005 21:56, kamal kc wrote:
the man pages use M_FOOBUF(where did it come from ??)
in the field type.
'foo' is a generic term for a random variable name.
Now how should i code it.
struct malloc_type mytype;
mytype=MALLOC_DEFINE(.,mybuffers,mybuffers);
what should i put
2005/10/17, kamal kc [EMAIL PROTECTED]:
sys/malloc.h has function prototypes for malloc()
kern/kern_malloc.c defines the malloc()
the malloc() definition is
void *
malloc(size, type, flags)
unsigned long size;
struct malloc_type *type;
int flags;
i
On 2005-06-30 22:27, Roman Kurakin [EMAIL PROTECTED] wrote:
Dmitry Mityugov wrote:
On 6/30/05, Roman Kurakin [EMAIL PROTECTED] wrote:
One simple question on programming style. Is it ok to call malloc
while we releasing some object?
Are you releasing it in another thread? Is it a C++ object?
On 6/30/05, Roman Kurakin [EMAIL PROTECTED] wrote:
Hi,
One simple question on programming style. Is it ok
to call malloc while we releasing some object?
Are you releasing it in another thread? Is it a C++ object? How are
you releasing it?
--
Dmitry
We live less by imagination than
Dmitry Mityugov wrote:
On 6/30/05, Roman Kurakin [EMAIL PROTECTED] wrote:
Hi,
One simple question on programming style. Is it ok
to call malloc while we releasing some object?
Are you releasing it in another thread? Is it a C++ object? How are
you releasing it?
This was
On Mon, 14 Feb 2005 08:04:50 -0500, David Schultz [EMAIL PROTECTED] wrote:
Right, databases, language runtimes, and the small set of other
applications for which it really matters usually have their own
special-purpose allocators. I was counting on that when I said
that replacing malloc() is
On Mon, Feb 14, 2005 at 02:08:07PM -0800, John-Mark Gurney wrote:
David Schultz wrote this message on Mon, Feb 14, 2005 at 08:04 -0500:
Right, databases, language runtimes, and the small set of other
applications for which it really matters usually have their own
special-purpose allocators.
Jason Henson wrote:
On 02/13/05 03:21:29, David Schultz wrote:
[...]
With a little bit of work, you should be able to replace
src/lib/libc/stdlib/malloc.c. ptmalloc is much more heavyweight,
but it would probably do better in cases where you have a large
number of threads doing a massive number
David Schultz wrote:
Other than that, I don't know enough
details about ptmalloc to speculate, except to say that for most
real-world workloads on modern systems, the impact of the malloc
implementation is likely to be negligible. Of course, test
results would be interesting...
Some language
On Mon, Feb 14, 2005, Andrew MacIntyre wrote:
David Schultz wrote:
Other than that, I don't know enough
details about ptmalloc to speculate, except to say that for most
real-world workloads on modern systems, the impact of the malloc
implementation is likely to be negligible. Of course, test
On Mon, 14 Feb 2005, Uwe Doering wrote:
Just from memory, doesn't Linux' malloc require kernel support for re-mapping
memory regions, which is not available in FreeBSD? This issue came up in the
discussion about FreeBSD's anemic realloc performance. Or has this kernel
functionality been added
David Schultz wrote this message on Mon, Feb 14, 2005 at 08:04 -0500:
Right, databases, language runtimes, and the small set of other
applications for which it really matters usually have their own
special-purpose allocators. I was counting on that when I said
that replacing malloc() is
On Mon, Feb 14, 2005, John-Mark Gurney wrote:
David Schultz wrote this message on Mon, Feb 14, 2005 at 08:04 -0500:
Right, databases, language runtimes, and the small set of other
applications for which it really matters usually have their own
special-purpose allocators. I was counting on
On Sun, Feb 13, 2005, Jason Henson wrote:
I saw on a few of the lists here how linux uses ptmalloc2 and it
outperforms bsd's malloc. I tried to do some research into it and
found PHK's pdf on it and it seems bsd's malloc was ment to be ok in
most every situation. Because of this it
On 02/13/05 03:21:29, David Schultz wrote:
On Sun, Feb 13, 2005, Jason Henson wrote:
I saw on a few of the lists here how linux uses ptmalloc2 and it
outperforms bsd's malloc. I tried to do some research into it and
found PHK's pdf on it and it seems bsd's malloc was ment to be ok
in
most
On Tue, 12 Oct 2004, Shawn Webb wrote:
(attached is the source code to the segfaulting application)
Doesn't appear to be -- if it was a large attachment, maybe the mailing
list stripped it. Could you give a URL for the source?
Robert N M Watson FreeBSD Core Team, TrustedBSD
, SNDCTL_DSP_SETRATE, arg) 0)
{
perror(ioctl setrate);
exit(1);
}
}
/* End of source */
- Original Message -
From: Robert Watson [EMAIL PROTECTED]
To: Shawn Webb [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, October 13, 2004 1:47 AM
Subject: Re: malloc calls and ioctl
In the last episode (Oct 14), Shawn Webb said:
I've got to rewrite the source due to hard disk problems, so I'll just put
it in this email:
arg = FORMAT;
if (ioctl(fd, SNDCTL_DSP_SETFMT, arg) 0)
{
perror(ioctl setfmt);
exit(1);
}
if (ioctl(fd,
On Fri, 13 Feb 2004, Andrew J Caines wrote:
After Ring the various FMs including, but not limited to, mdmfs(8),
mdconfig(8) malloc(9), I am unclear whether of not the memory used by md
of type MD_MALLOC is kernel memory which will not be swapped, or not.
On the same subject, does the the
At 00:56 14/02/2004, Robert Watson wrote:
If you
have swap available, you pretty much always want to use swap-backing for
memory disks -- if there's room in memory they will run as fast as
malloc-backed, but you don't have to be as worried about the Oh shoot,
I'm out of room case.
Actually,
On Sat, 14 Feb 2004, Colin Percival wrote:
At 00:56 14/02/2004, Robert Watson wrote:
If you
have swap available, you pretty much always want to use swap-backing for
memory disks -- if there's room in memory they will run as fast as
malloc-backed, but you don't have to be as worried about
Thus spake Danny Braniss [EMAIL PROTECTED]:
What a lame program...
If this program is indicative of your real-world work-load, you can
optimize a lot by getting better programmers.
If it is not indicative, then forget about it.
i wish i could :-)
A non-technical answer to your
In message [EMAIL PROTECTED], David Schultz writes:
You can find a somewhat more thorough comparison of malloc
implementations at http://citeseer.nj.nec.com/440671.html .
There are many problems with this paper, and my feeling is that it was
written with a very specific purpose in mind, although
Thus spake Poul-Henning Kamp [EMAIL PROTECTED]:
In message [EMAIL PROTECTED], David Schultz writes:
You can find a somewhat more thorough comparison of malloc
implementations at http://citeseer.nj.nec.com/440671.html .
There are many problems with this paper, and my feeling is that it was
In message [EMAIL PROTECTED], David Schultz writes:
Thus spake Poul-Henning Kamp [EMAIL PROTECTED]:
In message [EMAIL PROTECTED], David Schultz writes:
You can find a somewhat more thorough comparison of malloc
implementations at http://citeseer.nj.nec.com/440671.html .
There are many
Thus spake Poul-Henning Kamp [EMAIL PROTECTED]:
A harder problem to solve is fragmentation for long-running
servers, where the RSS tends to creep upwards over time as virtual
memory fills with holes.
This is where you want to run phkmalloc with the 'H' option.
It practically makes it a
What a lame program...
If this program is indicative of your real-world work-load, you can
optimize a lot by getting better programmers.
If it is not indicative, then forget about it.
i wish i could :-)
danny
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Danny Braniss wrote:
What a lame program...
If this program is indicative of your real-world work-load, you can
optimize a lot by getting better programmers.
If it is not indicative, then forget about it.
i wish i could :-)
This is a memory overcommit architecture.
If you want to
Your code is not efficient; try this instead:
He, the code is not mine, and the programmer is being invited for
some coffee and indocrination.
The program showed at least two things, 1- the linux emulation ignores
the datasize limit, 2- is faster for this particular case of bad programing.
[...]
If you want GNU malloc behaviour, then you should install the port
for the GNU allocator, and use it instead of the system allocator,
and you will end up with the same behaviour that your application
has on Linux.
what ticked my curiosity was that the linux binary did work, while
the
Danny Braniss wrote:
If you want GNU malloc behaviour, then you should install the port
for the GNU allocator, and use it instead of the system allocator,
and you will end up with the same behaviour that your application
has on Linux.
what ticked my curiosity was that the linux binary
Danny Braniss wrote:
Your code is not efficient; try this instead:
He, the code is not mine, and the programmer is being invited for
some coffee and indocrination.
Good.
The program showed at least two things, 1- the linux emulation ignores
the datasize limit,
Possibly. One would expect
[...]
Possibly. One would expect it to core, then, when you ran out of
memory; you said (in your original posting) that it was the FreeBSD
version of the code that cored?!?
true, but i also mentioned how i fixed it, by increasing the MAXDSIZ option.
danny
To Unsubscribe: send mail to
Terry Lambert [EMAIL PROTECTED] wrote:
The FreeBSD malloc guarantees that the pages are zeroed before being
obtained from the system; this is probably the majority of the cost.
It is a security measure, so that you do not leak data from one process
to another through anonymous pages.
The Linux
On Tue, Oct 22, 2002 at 01:20:42AM -0700, Terry Lambert wrote:
The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero.
The Linux malloc uses pages added to the process address space via
a call to sbrk.
There is no Linux malloc, neither does Linux have a sbrk syscall :)
But glibc
On Tue, Oct 22, 2002 at 01:52:34PM -0500, Stephen Montgomery-Smith wrote:
Brooks Davis wrote:
The user may also see a performance gain on Linux if they use a less
stupid allocation scheme. I ran into some code once that read strings
one character at a time via getc() and did a realloc
On Tue, Oct 22, 2002 at 12:01:19PM -0700, Terry Lambert wrote:
Tony Finch wrote:
Terry Lambert [EMAIL PROTECTED] wrote:
The FreeBSD malloc guarantees that the pages are zeroed before being
obtained from the system; this is probably the majority of the cost.
It is a security measure, so
Dan Nelson wrote:
The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero.
The Linux malloc uses pages added to the process address space via a
call to sbrk.
Actually, on FreeBSD only the page directory is mmap'ed. Data returned
to the user is allocated via sbrk.
Please see:
Brooks Davis wrote:
On Tue, Oct 22, 2002 at 01:20:42AM -0700, Terry Lambert wrote:
The FreeBSD malloc would be lower performance than the Linux malloc,
if you allocate space in teeny, tiny chunks; it has much higher
performance for large allocations. Good programmers allocate their
Tony Finch wrote:
The FreeBSD malloc guarantees that the pages are zeroed before being
obtained from the system; this is probably the majority of the cost.
It is a security measure, so that you do not leak data from one process
to another through anonymous pages.
The Linux
Dan Nelson wrote:
The only calls to sbrk have a 0 argument. This is only used to find
the segment end, so that the mmap's do not occur over top of anything
important.
Ah, but take a look at the calls to brk, especially in map_pages() and
free_pages().
How the anonymous pages (which I
On Tue, Oct 22, 2002 at 12:48:03PM -0700, Terry Lambert wrote:
Tony Finch wrote:
Linux [clears memory in the kernel before handing it over to
userland], and you appeared to be saying that it doesn't which
is clearly wrong for the security reasons that you stated. It
therefore won't
Tony Finch wrote:
You are arguing that there is nothing that can account for the
performance difference, when in fact there is a measured
performance difference.
No, I'm saying that some of what you said is either wrong or
misleading, and the comment about security was especially stupid.
Terry Lambert [EMAIL PROTECTED] wrote:
The security comment had to do with the fact that zeroing occurs in
the kernel in the idle loop, and can account for a large latency in
the case of a big demand in user space. It's a philosophy issue that
led to the implementation, and it has a performance
Tony Finch wrote:
You said that Linux doesn't guarantee to zero pages handed from the
system to userland, which is wrong. You've also mentioned the in-
kernel page-zeroing strategy which is irrelevant when comparing
different userland malloc implementations on the same OS.
No. I said:
| The
In the last episode (Oct 22), Terry Lambert said:
Danny Braniss wrote:
If you want GNU malloc behaviour, then you should install the
port for the GNU allocator, and use it instead of the system
allocator, and you will end up with the same behaviour that your
application has on Linux.
In the last episode (Oct 22), Terry Lambert said:
Dan Nelson wrote:
The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero.
The Linux malloc uses pages added to the process address space via a
call to sbrk.
Actually, on FreeBSD only the page directory is mmap'ed. Data
On Mon, Oct 21, 2002 at 11:25:43AM +0200, Danny Braniss wrote:
comments?
That code is a REALLY inefficient use of malloc(). You can always
write bizarre code that exaggerates the differences between different
algorithms (e.g. Linux malloc vs FreeBSD malloc).
Kris
msg37495/pgp0.pgp
On Fri, 3 Aug 2001, [iso-8859-1] vishwanath pargaonkar wrote:
Hi,
can anybody tell me in malloc what does third
parameter
DONTWAIT ,NOWAIT and WAITOK mean?
Bcoz i have function being called using timeout.in
that function i need to malloc a buffer.
can i use WAITOK?
please tell me abt
Chris Costello writes:
On Wednesday, August 02, 2000, Mike Smith wrote:
tcpcash_addr = (typeof(tcpcash_addr))
malloc(sizeof(*tcpcash_addr) *
TCPCASH_ROWSIZE *
TCPCASH_COOLSIZE);
Just as a note on coding
On Fri, 4 Aug 2000, Aleksandr A.Babaylov wrote:
Chris Costello writes:
On Wednesday, August 02, 2000, Mike Smith wrote:
tcpcash_addr = (typeof(tcpcash_addr))
malloc(sizeof(*tcpcash_addr) *
TCPCASH_ROWSIZE *
Chris Costello wrote:
On Wednesday, August 02, 2000, [EMAIL PROTECTED] wrote:
Sorry I have no other direction to ask this:
I have declaration:
u_int32_t *(tcpcash_addr[256]);
and want malloc some memory for tcpcash_addr:
tcpcash_addr =
Yes, and whan I use u_int32_t *(tcpcash_addr[256]) declaration,
I can use tcpcash_addr[x][y], and I must use
tcpcash_addr[x * 256 + y] if declaration is u_int32_t *tcphash_haddr,
I cant use if u_int32_t **tcphash_haddr,
because of need of array of pointers in addition to array of arrays,
It's only "clear" insofar as it's "clear" that the code is terrible.
Coffee first, critique second. 8)
#define TCPCASH_ROWSIZE 256
#define TCPCASH_COLSIZE 256
#define TCPCASH_ADDR(x) ((x) * TCPCASH_ROWSIZE)
#define TCPCASH_ADDR(x,y) ((y) * TCPCASH_ROWSIZE + (x))
--
[Charset iso-8859-1 unsupported, filtering to ASCII...]
It's only "clear" insofar as it's "clear" that the code is terrible.
Sorry I know English bad, do you want to say that my code is terrible?
Coffee first, critique second. 8)
#define TCPCASH_ROWSIZE 256
#define TCPCASH_COLSIZE
On Wednesday, August 02, 2000, Mike Smith wrote:
tcpcash_addr = (typeof(tcpcash_addr))
malloc(sizeof(*tcpcash_addr) *
TCPCASH_ROWSIZE *
TCPCASH_COOLSIZE);
Just as a note on coding style, this will
On Wednesday, August 02, 2000, [EMAIL PROTECTED] wrote:
Sorry I have no other direction to ask this:
I have declaration:
u_int32_t *(tcpcash_addr[256]);
and want malloc some memory for tcpcash_addr:
tcpcash_addr = (typeof(tcpcash_addr))malloc(u_int32_t * 256 * n);
and have an error:
Chris Costello wrote:
On Wednesday, August 02, 2000, [EMAIL PROTECTED] wrote:
Sorry I have no other direction to ask this:
I have declaration:
u_int32_t *(tcpcash_addr[256]);
and want malloc some memory for tcpcash_addr:
tcpcash_addr = (typeof(tcpcash_addr))malloc(u_int32_t *
79 matches
Mail list logo
