From owner-freebsd-arch  Fri Dec  8  4:13:40 2000
From owner-freebsd-arch@FreeBSD.ORG  Fri Dec  8 04:13:37 2000
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mail.interware.hu (mail.interware.hu [195.70.32.130])
	by hub.freebsd.org (Postfix) with ESMTP id 20F5537B400
	for <arch@freebsd.org>; Fri,  8 Dec 2000 04:13:37 -0800 (PST)
Received: from kairo-51.budapest.interware.hu ([195.70.50.115] helo=elischer.org)
	by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian))
	id 144MP7-0006vQ-00; Fri, 08 Dec 2000 13:13:33 +0100
Sender: julian@FreeBSD.ORG
Message-ID: <3A3000F6.52E9B1D9@elischer.org>
Date: Thu, 07 Dec 2000 13:28:22 -0800
From: Julian Elischer <julian@elischer.org>
X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en, hu
MIME-Version: 1.0
To: Kirk McKusick <mckusick@mckusick.com>
Cc: arch@freebsd.org
Subject: Re: Getting Kernel Process Information
References: <200012071938.LAA03622@beastie.mckusick.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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