On Fri, 2 Mar 2001, David Howells wrote:
>
> Surely, doing the merge will always have take longer than not doing the merge,
> no matter how finely optimised the algorithm... But merging wouldn't be done
> very often... only on memory allocation calls.
Ehh.. If the merging doesn't actually happ
On Fri, Mar 02, 2001 at 08:40:44AM +, David Howells wrote:
> no matter how finely optimised the algorithm... But merging wouldn't be done
> very often... only on memory allocation calls.
Correct, it would happen only at mmap time of course.
> Perhaps it'd be reasonable to only do VMA merging
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Also note that the merging tests were not free, so at least under my set of
> normal load the non-merging code is actually _faster_ than the clever
> optimized merging. That was what clinched it for me: I absolutely hate to
> see complexity that doesn't
Hi Linus,
On 1 Mar 2001, Linus Torvalds wrote:
> Note how do_brk() does the merging itself (see the comment "Can we
> just expand an old anonymous mapping?"), and that it's basically
> free when done that way, with no worries about locking etc. The same
> could be done fairly trivially in mmap to
On Thu, Mar 01, 2001 at 11:04:55AM -0800, David S. Miller wrote:
> Linus didn't find it to be such a gain, and in fact the one
> place that does gain from such merging (sys_brk()) does the
> merging by hand :-)
somewhere in either kernel or glibc we need to do the merging to avoid
allocating new
In article <[EMAIL PROTECTED]>,
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>On Thu, Mar 01, 2001 at 06:20:49PM +, Alan Cox wrote:
>> > It's not broken, it's not there any longer as somebody dropped it between test7
>> > and 2.4.2, may I ask why?
>>
>> Linus took it out because it was breaki
Andrea Arcangeli writes:
> If it happened to be buggy it didn't looked unfixable from a design standpoint
> and I think it was a very worthwhile feature, not just for memory but also to
> avoid growing the size of the avl that we would have to pay later all the time
> at each page fault.
Lin
On Thu, Mar 01, 2001 at 06:20:49PM +, Alan Cox wrote:
> > It's not broken, it's not there any longer as somebody dropped it between test7
> > and 2.4.2, may I ask why?
>
> Linus took it out because it was breaking things.
If it happened to be buggy it didn't looked unfixable from a design st
> It's not broken, it's not there any longer as somebody dropped it between test7
> and 2.4.2, may I ask why?
Linus took it out because it was breaking things.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
On Thu, Mar 01, 2001 at 03:24:09PM +0100, Andrea Arcangeli wrote:
> On Thu, Mar 01, 2001 at 12:16:08PM +0300, Ivan Stepnikov wrote:
> > if(p==malloc(block)){
>
> Side note: I guess here you meant:
>
> if ((p = malloc(block)) {
Actually
if (
On Thu, Mar 01, 2001 at 03:35:12PM +0100, Andrea Arcangeli wrote:
> From the above it's pretty obvious the clever vma merging is broken in 2.4.
It's not broken, it's not there any longer as somebody dropped it between test7
and 2.4.2, may I ask why?
Andrea
-
To unsubscribe from this list: send t
On Thu, Mar 01, 2001 at 12:27:53PM +0200, Matti Aarnio wrote:
> With malloc(1M):
>
> ...
> 44089000-4418a000 rw-p 00:00 0
> 4418a000-4428b000 rw-p 00:00 0
> 4428b000-4438c000 rw-p 00:00 0
> 4438c000-4448d000 rw-p 00:00 0
> 4448d000-4458e000 rw-p 000
On Thu, Mar 01, 2001 at 12:16:08PM +0300, Ivan Stepnikov wrote:
> if(p==malloc(block)){
Side note: I guess here you meant:
if ((p = malloc(block)) {
Make sure you catch when malloc returns null because of out of memory (the out
of memory in your case happened i
> memory area has to be accessed. In some memory management systems,
> the allocated area has to be actually written (demand zero paging).
> If you execute from a user account, not root, with ulimits enabled,
> you should be able to do:
> char *p;
> for(;;)
> {
> if(
On Thu, 1 Mar 2001, Ivan Stepnikov wrote:
> Hello!
>
> I tried to test linux memory allocation. For experiment I used i386
> architecture with Pentium III processor, 512M RAM and 8G swap space. For
> memory allocation libhoard was tried. Linux kernel 2.4.2 with patch
> per-process-3.
On Thu, Mar 01, 2001 at 12:16:08PM +0300, Ivan Stepnikov wrote:
> Hello!
>
> I tried to test linux memory allocation. For experiment I used i386
> architecture with Pentium III processor, 512M RAM and 8G swap space. For
> memory allocation libhoard was tried. Linux kernel 2.4.2 with p
Hello!
I tried to test linux memory allocation. For experiment I used i386
architecture with Pentium III processor, 512M RAM and 8G swap space. For
memory allocation libhoard was tried. Linux kernel 2.4.2 with patch
per-process-3.5G-IA32-no-PAE-1, at
/pub/linux/kernel/people/andrea/pa
17 matches
Mail list logo
