httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: FW: [PATCH] shmem.c
Date Mon, 10 Sep 2001 00:39:01 GMT
On Sunday 09 September 2001 17:23, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> Hi Ian,
> Thanks for the suggestion.. I certainly like the first idea (infact, that
> was also one of the idea I'd proposed earlier). But, I'm not sure how
> *open* are others to create a seperate shared memory just for maintaining
> the allocation table..

The only problem is going to be ensuring that the platform has enough
shared memory to handle both segments.  I think we can just return an
error if we run out of shared memory though.  IOW, +1 for having a second
shared memory segment for the control data.

Ryan

>
> As regards your second idea, I'm not comfortable with it - it'd introduce a
> lot of performance overhead - especially with IPC's around..
>
> Thanks for your suggestions..
> -Madhu
>
>
> -----Original Message-----
> From: Ian Holsman [mailto:ianh@cnet.com]
> Sent: Sunday, September 09, 2001 3:54 PM
> To: dev@httpd.apache.org
> Subject: Re: FW: [PATCH] shmem.c
>
>
> Hi Madhu.
> the only way I can think of handling this is to store the memory
> block list in another piece of shared memory/mmap (allocated seperatly)
>
> The other method I can think of is to spawn a seperate process which
> would hold all the memory list information, and it would do all the memory
> management
> and the other processes would communicate it via some IPC.
>
> the problem is that shared memory is NOT guarnteed to be in the same space
> for
> each process.
>
> ..Ian
>
> MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
> > Just forwarding it to the httpd mailing list - to get more inputs. [sorry
>
> if
>
> > duplicate]
> >
> > Thanks
> > -Madhu
> >
> > -----Original Message-----
> > From: MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)
> > [mailto:madhusudan_mathihalli@hp.com]
> > Sent: Sunday, September 09, 2001 1:13 AM
> > To: 'dev@apr.apache.org'
> > Subject: RE: [PATCH] shmem.c
> >
> >
> > Sorry for the delay in replying.. But, I'm wondering if it's at all
>
> possible
>
> > to do any meaningful memory management without storing the
> > characteristics of the memory chunk / block allocated.. By "meaningful
> > memory mgmt", I
>
> mean
>
> > a facility where freed memory blocks are tracked, and reallocated based
> > on the need/requirement.
> >
> > I might be missing something here - but it'd be great if somebody would
>
> give
>
> > me one possible way of doing such a thing.. I'd be happy to implement
> > it..
> >
> >
> > Pl. note that I'm not trying to question somebody's authority here, but
> > because of my *limited apache knowledge*, I'm trying to get a better
> > understanding of memory mgmt in apache.
> >
> > Thanks
> > -Madhu
> >
> >
> >
> >
> > -----Original Message-----
> > From: Justin Erenkrantz
> > To: dev@apr.apache.org
> > Sent: 9/8/01 12:59 AM
> > Subject: Re: [PATCH] shmem.c
> >
> > On Fri, Sep 07, 2001 at 11:49:15PM -0700, MATHIHALLI,MADHUSUDAN
> >
> > (HP-Cupertino,ex1) wrote:
> >>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.
> >
> > -1 (veto) if it means that we can't do:
> >
> > - Create 1024KB shared memory segment
> > - Allocate 256KB from that segment
> > - (Repeat above three more times)
> >
> > This was the problem inherent with MM and which is why it was removed.
> >
> > The problem is that you can't often allocate more than what the user
> > asked for because of hard system limits.  (Therefore, you can't create
> > a segment size of 1030KB when they ask for 1024KB because the system
> > has a upper bound of 1024KB...).  -- justin

-- 

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message