You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@hp.com> on 2001/09/08 03:19:27 UTC
[PATCH] shmem.c
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)
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
Re: [PATCH] shmem.c
Posted by Ian Holsman <Ia...@cnet.com>.
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
Re: [PATCH] shmem.c
Posted by Ian Holsman <Ia...@cnet.com>.
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