[OpenAFS-devel] AFSD memory footprint

[Derek Atkins]

Ok, I'll work on a patch and send it in.

-derek

"Neulinger, Nathan" <nneul@umr.edu> writes:

> I did some limited testing allocating, writing, and freeing a couple large
> chunks of memory. On linux, it definately returns the memory to the O/S when
> you free() it with redhat-6.2 or 7.1.  (I think glibc 2.1 and 2.2
> respectively.)
> 
> I couldn't get hp or solaris to give me any meaningful results. (It didn't
> look like malloc'd data was showing up in ps SZ column, but I may have been
> doing something stupid.)
> 
> I'd say it'd certainly be worth free'ing the data on linux, and everywhere
> else - if for no other reason than that Nikolai mentioned - just to be
> correct.
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > Sent: Thursday, August 02, 2001 1:50 PM
> > To: Neulinger, Nathan
> > Cc: openafs-devel@openafs.org
> > Subject: Re: [OpenAFS-devel] AFSD memory footprint
> > 
> > 
> > That is one approach.. But then you have to wait and catch the child
> > process when it ends.  Also, I think there might be a synchronization
> > issue there, in terms of when you need to sweep the cache.
> > 
> > -derek
> > 
> > "Neulinger, Nathan" <nneul@umr.edu> writes:
> > 
> > > I think that'll probably depend on which os/kernel. Depends 
> > on whether the
> > > o/s will de-allocate when unused.
> > > 
> > > There might be another option - what about forking itself 
> > and passing the
> > > limited info needed, and then terminating the process that 
> > did all the
> > > allocations? (Not sure if this is feasible, just an idea.)
> > > 
> > > -- Nathan
> > > 
> > > > -----Original Message-----
> > > > From: Derek Atkins [mailto:warlord@MIT.EDU]
> > > > Sent: Thursday, August 02, 2001 1:29 PM
> > > > To: openafs-devel@openafs.org
> > > > Subject: [OpenAFS-devel] AFSD memory footprint
> > > > 
> > > > 
> > > > So, afsd winds up mallocing a lot of memory during it's 
> > cache sweep
> > > > and startup stages.  I don't think it needs most of that 
> > memory by the
> > > > time it calls into the kernel.  Is there any reason that we don't
> > > > 'free()' that memory before the last afs_syscall()?  I'm 
> > thinking that
> > > > this could potentially free a few megabytes of RAM.  Or 
> > will it not
> > > > matter since the virtual memory is already mapped into the process
> > > > space?
> > > > 
> > > > -derek
> > > > -- 
> > > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> > > >        Member, MIT Student Information Processing Board  (SIPB)
> > > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> > > >        warlord@MIT.EDU                        PGP key available
> > > > _______________________________________________
> > > > OpenAFS-devel mailing list
> > > > OpenAFS-devel@openafs.org
> > > > https://lists.openafs.org/mailman/listinfo/openafs-devel
> > > > 
> > > _______________________________________________
> > > OpenAFS-devel mailing list
> > > OpenAFS-devel@openafs.org
> > > https://lists.openafs.org/mailman/listinfo/openafs-devel
> > 
> > -- 
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >        warlord@MIT.EDU                        PGP key available
> > 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available