Hello.
This is just an initial/preliminary heads-up, maybe mis-directed, about
a possible issue.
I upgraded 2 machines today to 3.10.25, and both shows some.. strangeness
within linux guests, which are also running 3.10.25. Revering to 3.10.24
in guests (compiled by the same compiler with the
Hello.
This is just an initial/preliminary heads-up, maybe mis-directed, about
a possible issue.
I upgraded 2 machines today to 3.10.25, and both shows some.. strangeness
within linux guests, which are also running 3.10.25. Revering to 3.10.24
in guests (compiled by the same compiler with the
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
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
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
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
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 too,
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
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
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 happen,
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
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.
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
> 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
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
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
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
> 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(;;)
> {
>
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
>
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
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
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
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 patch
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
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((p =
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
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 00:00
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
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
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
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 breaking things.
If
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.
Linus
34 matches
Mail list logo
