Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Sep 2004 17:40:27 -0700
From:      Julian Elischer <julian@elischer.org>
To:        David Schultz <das@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern kern_proc.c kern_switch.c src/sys/sys sched.h src/sys/vm vm_glue.c
Message-ID:  <414E26FB.4010606@elischer.org>
In-Reply-To: <20040920001317.GA2829@VARK.MIT.EDU>
References:  <200409191834.i8JIYHXU089517@repoman.freebsd.org> <414E0DCA.5090601@elischer.org> <20040920001317.GA2829@VARK.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote:
> On Sun, Sep 19, 2004, Julian Elischer wrote:
> 
>>David Schultz wrote:
>>
>>>das         2004-09-19 18:34:17 UTC
>>>
>>> FreeBSD src repository
>>>
>>> Modified files:
>>>   sys/kern             kern_proc.c kern_switch.c 
>>>   sys/sys              sched.h 
>>>   sys/vm               vm_glue.c 
>>> Log:
>>> The zone from which proc structures are allocated is marked
>>> UMA_ZONE_NOFREE to guarantee type stability, so proc_fini() should
>>> never be called.  Move an assertion from proc_fini() to proc_dtor()
>>> and garbage-collect the rest of the unreachable code.  I have retained
>>> vm_proc_dispose(), since I consider its disuse a bug.
>>
>>well we do aim to one day remove the requirement for UMA_ZONE_NOFREE.
>>In fact I have a gague feeling we mayhave already done so. I think it
>>had to do with what page tables the kernel ran on after a thread went away.
>>Peter may have a better memory as to why that was required.
> 
> 
> We are clearly not there yet for things like p_vmspace.  Look at
> sys_process.c or procfs, for instance.  But I don't mind backing
> this out if someone is imminently preparing to remove the
> requirement.

it can probably stay out for now. I just thought I'd mention it..

> 
> By the way, it would be great if someone who understands it better
> could edit the comments in sys/proc.h to reflect reality,
> particularly with respect to the locking model.  Some of it seems
> to have rotted.  For example, (l) and (m) are unused and p_stats
> looks like it should be (c + j).

I plan to edit all the comments WRT threads and processes. I need a day with no 
bugs.. :-) I also plane to write  a proc/ksegrp/thread man page in '9'
giving the theory on how it all fits together.

I believe jhb has a p4 branch in which he is polishing locking stuff.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?414E26FB.4010606>