This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: cyg_mempool_info - var and fix
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Subject: Re: [ECOS] cyg_mempool_info - var and fix
- From: Srinivasan Sriram <pet_jimmy at yahoo dot com>
- Date: Thu, 21 Jun 2001 03:44:10 -0700 (PDT)
- Cc: ecos-discuss at sourceware dot cygnus dot com
Could you please explain the following behaviour when
working with var memory pool? As you had previously
replied maxfree component of cyg_mempool_info has some
bug. Now Considering the component freemem -
PROBLEM 1:
I create a var mempool of size 4096.
1. I use cyg_mempool_var_alloc and first try to
allocate a block of 4000
2. Then a block of size 24
3. Finally a block of size 5.
The following the o/p I get. The first 2 allocations
succeed but the third fails.
*************1***************
totalmem 4080
freemem 64
base 63648
size 4096
blocksize -1
maxfree 64 /*SHOULD HAVE BEEN 64-16*/
try alloc 63740
*************2***************
totalmem 4080
freemem 16 /*SHOULD HAVE BEEN 64-(24+16)=24*/
base 63648
size 4096
blocksize -1
maxfree 16 /*SHOULD HAVE BEEN 8*/
try alloc 63692
*************3***************
totalmem 4080
freemem 16
base 63648
size 4096
blocksize -1
maxfree 16
try alloc 0 /*REQUEST FOR A BLOCK SIZE OF 5 SHOULD
HAVE SUCCEEDED.BUT IT FAILS..HOWEVER REQUEST OF BLOCK
SIZE 4 IS A SUCCESS HERE.*/
-----------------
I change the input parameters and run the program
again.
This time
1. request for block size 4000
2. block size 20
3. block size 20
This is the o/p.
Strangely memory blocks of 4000,20 and 20 are all
allocated!
----
*************1***************
totalmem 4080
freemem 64
base 63648
size 4096
blocksize -1
maxfree 64 /*SHOULD HAVE BEEN 48 */
try alloc 63740
*************2***************
totalmem 4080
freemem 32 /* 64-(20+16)=28 */
base 63648
size 4096
blocksize -1
maxfree 32 /* 28-16 =12 */
try alloc 63708
*************3***************
totalmem 4080
freemem 0
base 63648
size 4096
blocksize -1
maxfree 0
try alloc 63676 /*REQUEST FOR 20 BLOCKS SHOULD HAVE
FAILED INSTEAD MEM IS ALLOCATED*/
I
PROBLEM 2:
In case of fixed memory pools - I encounter the
following problem.
I create a mempool of size 4000. I set block size
=1000.
I use the call cyg_mempool_fix_alloc and try to
allocate blocks of size 1000.
The allocation happens 3 times. 4th time it fails.
Assuming some part of the pool is USED for storing
some info during each info, the mempool_info structure
puzzles me.
This is the o/p I get for fixed block allocation.
-----------
***1***
totalmem 3000
freemem 2000
base 71904
size 4000
blocksize 1000
maxfree 1000
alloc1 - 72904
*** 2 ****
totalmem 3000
freemem 1000
base 71904
size 4000
blocksize 1000
maxfree 1000
alloc2 - 73904
*** 3 ****
totalmem 3000
freemem 0
base 71904
size 4000
blocksize 1000
maxfree 1000
alloc3 - 74904
---------------
WHY HAS THE totalmem reduced to 3000?
Also if I initialize my block size to 100, the
totalmem
becomes 4000-100=3900.
Is totalmem=size of mempool-block size in case of
fixed
mempools?
Thanks
Kavita
--- Jonathan Larmour <jlarmour@redhat.com> wrote:
> Srinivasan Sriram wrote:
> >
> > Hello!
> >
> > I create a variable memory pool of size 4096.
> > A thread claims a block size of 4000.
> >
> > typedef struct {
> > cyg_int32 totalmem;
> > cyg_int32 freemem;
> > void *base;
> > cyg_int32 size;
> > cyg_int32 blocksize;
> > cyg_int32 maxfree; // The largest free block
> > } cyg_mempool_info;
> >
> > Using this structure I get -
> >
> > totalmem 4080
> > freemem 64
> > base 71776
> > size 4096
> > blocksize -1
> > maxfree 64
> >
> > ---
> >
> > Though maxfree is 64, I'm unable to even obtain a
> > block of 60 from the pool.
>
> That's a bug. In this case it should have been
> 64-16=48 bytes.
>
> > How did the figure of 64 end up as freemem? (It
> should
> > be more).
>
> Some of the pool is used for metadata stored with
> each allocation. That's
> why maxfree exists (once it works ;-)).
>
> > And how do I compute how much memory is now
> available
> > in the pool so that my mempool_var_alloc will not
> > fail?
>
> maxfree once it works.
>
> I'll check in a fix which should appear in anonCVS
> in the next update.
>
> Jifl
> --
> Red Hat, Rustat House, Clifton Road, Cambridge, UK.
> Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous
> Huxley || Opinions==mine
> Come to the Red Hat TechWorld open source conference
> in Brussels!
> Keynotes, techie talks and exhibitions
http://www.redhat-techworld.com/
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/