From owner-cvs-sys  Thu Feb 20 05:53:34 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA13445
          for cvs-sys-outgoing; Thu, 20 Feb 1997 05:53:34 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA13400;
          Thu, 20 Feb 1997 05:52:57 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id AAA02079; Fri, 21 Feb 1997 00:47:02 +1100
Date: Fri, 21 Feb 1997 00:47:02 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199702201347.AAA02079@godzilla.zeta.org.au>
To: ache@nagual.ru, bde@freefall.freebsd.org
Subject: Re: cvs commit:  src/sys/kern sys_generic.c
Cc: cvs-all@freefall.freebsd.org, CVS-committers@freefall.freebsd.org,
        cvs-sys@freefall.freebsd.org
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>Thanks, but I see no commit for removing p_selbits_size and p_selbits
>fields from struct proc... kern_exit.c also does free for p_selbits and
>needs fixing after remove.

I'll leave them until it is decided that the caching scheme is unnecssary.

>BTW, do we really need free() of malloc storage before return? If program
>use huge select once, in most practical cases it will mean that the same
>select code will be executed again, i.e. the same hudge select will be
>malloced/freeed. Maybe return to old p_selbits caching scheme?

Maybe, but I think there are more important things to cache, starting
with the 1K namei buffer.  Most processes don't do many lookups, but
things like `find / -xdev -type f' do a lot (about 4 per file).  I
think this isn't worth optimizing either :-).

Bruce