apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathiha...@hp.com>
Subject RE: [PATCH] shmem.c
Date Sat, 08 Sep 2001 06:49:15 GMT
Hi Ian,
  Thanks for x-posting it to the apr mailing list.

As regards the shmem_t, you're right.. I'm working on having it as a part of
the shared memory itself - but I'm not sure if such a thing is  acceptable..
I was thinking of the following 2 alternatives (1) store the shmem_t
structure in the shared memory (either a different one or in the same shared
memory segment) OR (2) store the memchunk characteristics along with the
memory chunk - similar to MM.

Pl. let me know your views / suggestions..

Thanks
-Madhu

-----Original Message-----
From: Ian Holsman
To: dev@httpd.apache.org
Cc: dev@apr.apache.org
Sent: 9/7/01 8:11 PM
Subject: Re: [PATCH] shmem.c

x-posting to dev@apr.apache.org, as this is a APR issue

On Fri, 2001-09-07 at 18:19, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
wrote:
> Hi Cliff,
> 	I've also been working in the memory management area over the
last
> couple of days, towards adding more memory management capability to
the
> SHMEM code.. Here's a patch including the changes I've been working
on.
> 
> Summary of the enhancements to SHMEM :
> --------------------------------------
> 1. Keep track of the memory chunks allocated (a linked list of the
allocated
> blocks)

we had this intially in the original shmem implementation, and it caused
problems.

a person would allocate 1M, and would allocate 4 256K chunks and fail.
this was due to keep a linked list.

just some a comment on the patch which might be problematic.

you keep pointers in shmem_t.
this won't work, as shmem might be at a different address in different
processes.


..Ian
> 2. Provide the "realloc" functionality 
> 3. Maintain a list of the memory chunks that were "freed" so that
those
> chunks can be reused for future memory allocations.
> 
> With this enhanced capability, it'd be easier to enable the SHMHT and
the
> SHMCB modes of SSL Session Caching. I'm also working on porting the
> ssl_scache_shmht.c and ssl_scache_shmcb.c, and should be submitting a
patch
> soon.
> 
> Pl. let me know if it helps in satisfying the memory mgmt. problems
that
> you're trying to resolve. If not, I'd like to work with you to add any
> additional functionality.
> 
> Pl. review the changes and commit it accordingly. Any feedback /
inputs are
> welcome.
> 
> Thanks
> -Madhu
> 
> 
> 
> -----Original Message-----
> From: jwoolley@apache.org [mailto:jwoolley@apache.org]
> Sent: Friday, September 07, 2001 1:05 PM
> To: httpd-2.0-cvs@apache.org
> Subject: cvs commit: httpd-2.0 STATUS
> 
> 
> jwoolley    01/09/07 13:05:07
> 
>   Modified:    .        STATUS
>   Log:
>   Bright and sunny in C'ville...
>   
>   Revision  Changes    Path
>   1.287     +10 -7     httpd-2.0/STATUS
>   
>   Index: STATUS
>   ===================================================================
>   RCS file: /home/cvs/httpd-2.0/STATUS,v
>   retrieving revision 1.286
>   retrieving revision 1.287
>   diff -u -d -u -r1.286 -r1.287
>   --- STATUS	2001/09/07 14:01:26	1.286
>   +++ STATUS	2001/09/07 20:05:06	1.287
>   @@ -1,5 +1,5 @@
>    APACHE 2.0 STATUS:
-*-text-*-
>   -Last modified at [$Date: 2001/09/07 14:01:26 $]
>   +Last modified at [$Date: 2001/09/07 20:05:06 $]
>    
>    Release:
>    
>   @@ -142,12 +142,15 @@
>          longer needed. Enabling simple debugging features like guard
>          bands, double free detection, etc. would be cool but
certainly
>          not a hard requirement.
>   -        Status: Cliff, David, et al have discussed using the blocks
SMS
>   -	        for this.  First step is to s/malloc/apr_sms_malloc/g,
etc.
>   -		We could then have a thread-private SMS that is pointed
>   -		to by the conn_rec's or something so that all calls to
>   -		the bucket create functions can pass in that SMS.  No
locks
>   -		required.  Should be fast... 
>   +
>   +          Status: Cliff started to implement this using SMS as has
>   +                  been discussed at length for months, but since
>   +                  SMS is not being used anywhere else in the
server,
>   +                  several people expressed the opinion that we
should
>   +                  get rid of it entirely, meaning that the buckets
>   +                  need their own memory management (free list)
functions.
>   +                  Cliff will implement that this weekend so we at
least
>   +                  have something to look at/compare with.
>    
>        * Eliminate unnecessary creation of pipes in mod_cgid
>    
>   
>   
>   
> 
> 
-- 
Ian Holsman
Performance Measurement & Analysis
CNET Networks    -    415 364-8608

Mime
View raw message