(unknown charset) Re: where to release proc.p_stats

On Fri, Oct 21, 2005, John Baldwin wrote:
> On Friday 21 October 2005 09:13 am, nocool wrote:
> > freebsd-hackersļ¼Œhello
> >
> > 	Question about 5.4 kernel source code.
> > 	I have some question about strust proc's initialize. Kernel use proc_zone
> > to allocate proc items and initialize them with proc_init
> > (sys\kern\kern_proc.c) function. In this function, we can find the field
> > proc.p_stats is allocated with pstats_alloc(), as
> >
> > p->p_stats = pstats_alloc();
> >
> > and pstats_alloc is realized as
> >
> > malloc(sizeof(struct pstats), M_SUBPROC, M_ZERO|M_WAITOK);
> >
> > But I can't find where this field is freed. If it will not be release, will
> > there be memory leakage?
> 
> Heh, das_at_ forgot to call pstats_free() when he did the changes.  The reason 
> is probably because proc_fini() doesn't do anything useful because we never 
> recycle proc structs.  We should probably at least add the operations there 
> though for documentation purposes.  Something like this would work I think:

I didn't put in the call because we never free proc structures, but
documenting what should happen if we ever do free them is a good
idea.  There's a fair amount of other cleanup that needs to happen
as well, which you can probably find in the CVS history.  (IIRC,
I'm guilty of removing the code at a time when more things depended
upon struct proc being type safe.  Are there any remaining reasons
why we can't free struct procs at this point?)

By the way, there's no reason why we can't fold struct pstats into
struct proc so we don't have to allocate and free it at all.
It's never shared, so the extra level of indirection just adds overhead.
The main reason I didn't make this change earlier was to maintain binary
compatibility when I backported my U-area changes to -STABLE.