Date: Thu, 07 Dec 2000 13:28:22 -0800 From: Julian Elischer <julian@elischer.org> To: Kirk McKusick <mckusick@mckusick.com> Cc: arch@freebsd.org Subject: Re: Getting Kernel Process Information Message-ID: <3A3000F6.52E9B1D9@elischer.org> References: <200012071938.LAA03622@beastie.mckusick.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk McKusick wrote:
>
> For the third time in a week, I got the following message when I
> tried to run ps on my 5.X system:
>
> proc size mismatch (39776 total, 1136 chunks)
>
> This message arises when the size of the proc structure changes.
> With the current SMP development, the proc structure changes at
> a very high rate of speed. The current kinfo_proc interface used
> between the kernel and user processes is built from two pieces:
>
> struct kinfo_proc {
> struct proc kp_proc;
> struct eproc kp_eproc;
> }
>
> Kinfo_proc contains a copy of the kernel's proc structure
> followed by an `extended' proc structure which has lots
> of bits and pieces that have moved out of the proc structure
> or are otherwise needed. Any change to the kernel's version
> of the proc structure changes the size of the kinfo_proc
> structure and hence causes a mismatch when attempts are made
> to copy it out.
>
> I propose to change the kinfo_proc structure. The new
> kinfo_proc structure will contain only the stylized `extended'
> proc structure which will be augmented with the twenty
> fields that are actually referenced from the proc structure
> by user processes. By taking this approach, changes to the
> proc structure will not affect the format or size of the
> kinfo_proc structure returned to user processes. The new
> `extended' proc structure will have plenty of spare fields
> added to its end so that when new fields are added to the
> proc structure that user-level processes need/want to know
> about, they can be added without changing the size of the
> exported kinfo_proc structure and thus will not require
> recompilation of the dozen or so programs that use the
> exported interface. Note that even if 200 spare bytes are
> added to the kinfo_proc structure, it will still be smaller
> than the current one.
A good idea.
I would like to add that if we get our war and split
struct proc
into :
1/ struct proc
2/ schedulabel entity
3/ Sleepable entity
4/ (possibly a linking structure for the above)
then all this would have to change anyhow. It seems possible
that your change might insulate us from the pain of that
happenning.
When is the information copied from the proc structure into the
kinfo_proc stucture?
In the case of the threaded split world we are considering
some of the numbers would be totals from the subprocesses
schedulable entities.
>
> Note that I am proposing to make this change only in the
> 5.X tree. I am not proposing that it be back ported to the
> 4.X tree.
>
> I am not interested in starting a long discussion on all
> the possible alternatives for exporting kernel information
> to user processes. I recognize that there are better ways
> to handle these issues. I am just trying to make an
> incremental change that is small in scope and hopefully
> will make an annoying problem significantly less common.
> With this caveat, comments are solicited.
go for it
>
> Kirk McKusick
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
--
__--_|\ Julian Elischer
/ \ julian@elischer.org
( OZ ) World tour 2000
---> X_.---._/ presently in: Budapest
v
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A3000F6.52E9B1D9>