This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: cyg_mempool_info - var and fix


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]