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


You have too many questions for one mail, so I'll only answer some of them.
Someone else can answer the others. Also please trim quoted text.

Srinivasan Sriram wrote:
> 
> 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*/

If you suspect a problem here, turn on assertions (using CYG_INFRA_DEBUG).

> 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?

One block is taken for admin.
 
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/


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