Here is an exchange I had with Tomasz a while back regarding mbuff and buffer sizes.  
I am not sure if this is the definitive answer but it may help a few people out.

It is a little long winded but it covers a lot of investigation effort.

Rich



 -----Original Message-----
From:   Basham, Richard R  
Sent:   Friday, October 20, 2000 12:43 PM
To:     'Tomasz Motylewski'
Subject:        [rtl] mbuff driver 0.7.2

Tomasz,

I have been playing around with mbuff and I may have discovered a bug.

Is there a limit to the buffer size of any single buffer?

I have a machine with 1 Gig of memory and so I was just playing around
to see just how much memory I could allocate in mbuff.  I just modified
the demo.c file.  I added a multiplier to your specification of 1024*1024 bytes
for the demo buffers.  I found that if I exceeded 1024*1024*51 
(I have tried 52 & 64) when allocating the buffers it hangs my entire system.
I have to reset the system. (painful)   Note, when I use 52 it reboots my 
system for me.  When I use 64 it just hangs the system with the existing 
display showing.  I added two more buffers using 1024*1024*51 so that there 
were a total of four buffers being allocated and it worked fine.

I have been using xosview to watch my system memory.  When mbuff is working
I see very little activity in the amount of memory being used.  However, if mbuff 
hangs the machine, after the reboot xosview shows something like 837Meg in use.
I have to reboot again to clear this.

I hope I have provided enough information for you to be able to answer my question at 
the top.  If it is a bug, well then, oops. :)

Thanks in advance,
Rich


----------
From:   Tomasz Motylewski[SMTP:[EMAIL PROTECTED]]
Sent:   Friday, October 20, 2000 11:09 AM
To:     Basham, Richard R
Subject:        Re: [rtl] mbuff driver 0.7.2

On Fri, 20 Oct 2000, Basham, Richard R wrote:

> Is there a limit to the buffer size of any single buffer?

I am not aware of any, but there might be a limit for the size of mapped
area.

Could you make  a module containing just

ptr=vmalloc(1024*1024*100)

in init_module

and

vfree(ptr) in cleanup module?

> I have a machine with 1 Gig of memory and so I was just playing around
> to see just how much memory I could allocate in mbuff.  I just modified
> the demo.c file.  I added a multiplier to your specification of 1024*1024 bytes
> for the demo buffers.  I found that if I exceeded 1024*1024*51 

Mbuff was never tested with so much memory. Eiter error during allocation, or
more probable is that it it not possible to map bigger blocks.

> I have been using xosview to watch my system memory.  When mbuff is working
> I see very little activity in the amount of memory being used.  However, if mbuff 
> hangs the machine, after the reboot xosview shows something like 837Meg in use.
> I have to reboot again to clear this.

Funny.

> 
> I hope I have provided enough information for you to be able to answer my
> question at the top.  If it is a bug, well then, oops. :)

I will ask my friend, I think Linux had some limit of mappable memory. To be
overcome by changing some kernel header file and recompiling.

--
Tomek


 -----Original Message-----
From:   Basham, Richard R  
Sent:   Friday, October 20, 2000 3:42 PM
To:     'Tomasz Motylewski'
Subject:        RE: [rtl] mbuff driver 0.7.2


Tomasz,

I just quickly put those two lines into the frank example and it worked for 
1024*1024*50 but when I put in 1024*1024*52 it reboot my machine.  
I think that yes indeed there is a limit for the size of a mapped area.
I would like to know if you find out more about this limit.

Thanks,
Rich


----------
From:   Tomasz Motylewski[SMTP:[EMAIL PROTECTED]]
Sent:   Sunday, October 22, 2000 2:36 PM
To:     Basham, Richard R
Subject:        RE: [rtl] mbuff driver 0.7.2

On Fri, 20 Oct 2000, Basham, Richard R wrote:

> I just quickly put those two lines into the frank example and it worked for 
> 1024*1024*50 but when I put in 1024*1024*52 it reboot my machine.  
> I think that yes indeed there is a limit for the size of a mapped area.
> I would like to know if you find out more about this limit.

If this happens just by vmalloc, it has nothing to do with mbuff, because
vmalloc is built-in Linux function, used by mbuff.

Look at /usr/src/linux/include/asm/shmparam.h, I have heard some people were
changing this file to get more shared memory. As of now the limit for a
single block seems to be 32 MB (SHMMAX). But to change it, also some other
parameters in this file have to be changed.

By the way, have you really tested your computer well? Try to run the
following user space program with single numeric argument, increasing from
50000000 B to about 800 MB.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define PAGE_L  4096
int main(int argc, char *argv[])
{
        char *buf;
        unsigned len,i;

        len=70*1024*1024;
        if( argc > 1)
                sscanf(argv[1],"%d",&len);

        buf=malloc(len);

        for(i=0; i<len; i+=PAGE_L)
                buf[i]=4;

        sleep(1);
        free(buf);
        return(0);
}

> > Could you make  a module containing just
> > 
> > ptr=vmalloc(1024*1024*100)
> > 
> > in init_module
> > 
> > and

Another nice stress test for you would be to "make clean" in your kernel
source directory (or copy "cp -a" of it) and then "make -j 10 bzImage" (or
even -j 30 with this amount of memory)

Best regards,
--
Tomek


 -----Original Message-----
From:   Basham, Richard R  
Sent:   Monday, October 23, 2000 11:11 AM
To:     'Tomasz Motylewski'
Subject:        RE: [rtl] mbuff driver 0.7.2

Tomasz,

I checked SHMAX and yes indeed it is set to 32 MB.  It says in the file not to change 
that value because so many others depend on that value.  Therefore I will not change 
that value.

I ran your program allocating up to 900 MB and it worked just fine.  I takes about 10 
seconds to allocate and fill 900 MB per your example.  

I did the make -j 10 bzImage and it stressed the cpu more than the memory.  I suspect 
that if I ran make -j 30 bzImage that it would use all of the available memory and a 
little swap space.  

In general I would say that everything is working as expected.  It might be a good 
thing to document the maximum size of a single buffer in your README or FAQ file.

Thanks allot for the help.  I learned a few things going through all of this.

Rich



----------
From:   Tomasz Motylewski[SMTP:[EMAIL PROTECTED]]
Sent:   Monday, October 23, 2000 4:17 PM
To:     Basham, Richard R
Subject:        RE: [rtl] mbuff driver 0.7.2

On Mon, 23 Oct 2000, Basham, Richard R wrote:

> I checked SHMAX and yes indeed it is set to 32 MB.  It says in the file
> not to change that value because so many others depend on that value.  
> Therefore I will not change that value.

I think some people running huge calculations were chaning it without bad
effects.

> I ran your program allocating up to 900 MB and it worked just fine.  I
> takes about 10 seconds to allocate and fill 900 MB per your example.

But this means there is a way to allocate so much memory. Then I am suprised
vmalloc does not work.

> In general I would say that everything is working as expected.  It might
> be a good thing to document the maximum size of a single buffer in your
> README or FAQ file.

I am still not convinced that this is not a bug somewhere. I will have to
test it myself.

Best regards,
--
Tomek


 -----Original Message-----
From:   Basham, Richard R  
Sent:   Monday, October 23, 2000 8:42 PM
To:     'Tomasz Motylewski'
Subject:        RE: [rtl] mbuff driver 0.7.2

Maybe the answer lies in the differences between malloc and vmalloc.  
However, I am not an expert in this area.

Rich


----- End of forwarded message from [EMAIL PROTECTED] -----
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/

Reply via email to