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: Srinivasan Sriram <pet_jimmy at yahoo dot com>
- Subject: Re: [ECOS] cyg_mempool_info - var and fix
- From: Jonathan Larmour <jlarmour at redhat dot com>
- Date: Thu, 21 Jun 2001 12:12:20 +0100
- Cc: ecos-discuss at sourceware dot cygnus dot com
- Organization: Red Hat UK Ltd.
- References: <20010621104410.64808.qmail@web14005.mail.yahoo.com>
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/