headers
Simon Burge | 1 Aug 2002 03:26

Culling a few calls to microtime()

This is a little change to reduce a few calls to microtime() based on
some other similar code in the kernel.  Seem reasonable?

Simon.
--
Simon Burge                                   <simonb <at> wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/

Index: miscfs/kernfs/kernfs_vnops.c
===================================================================
RCS file: /cvsroot/syssrc/sys/miscfs/kernfs/kernfs_vnops.c,v
retrieving revision 1.82
diff -d -p -u -r1.82 kernfs_vnops.c
--- miscfs/kernfs/kernfs_vnops.c	2002/07/19 18:35:44	1.82
+++ miscfs/kernfs/kernfs_vnops.c	2002/08/01 01:21:44
 <at>  <at>  -466,7 +466,6  <at>  <at>  kernfs_getattr(v)
 	} */ *ap = v;
 	struct vnode *vp = ap->a_vp;
 	struct vattr *vap = ap->a_vap;
-	struct timeval tv;
 	int error = 0;
 	char strbuf[KSTRING], *buf;

 <at>  <at>  -478,10 +477,11  <at>  <at>  kernfs_getattr(v)
 	vap->va_size = 0;
 	vap->va_blocksize = DEV_BSIZE;
 	/*
-	 * Make all times be current TOD.
+	 * Make all times be current TOD.  Avoid microtime(9), it's slow.
+	 * We don't guard the read from time(9) with splclock(9) since we
(Continue reading)

Permalink | Reply | 32 comments |
headers
itojun | 1 Aug 2002 04:43

Re: Culling a few calls to microtime()

>This is a little change to reduce a few calls to microtime() based on
>some other similar code in the kernel.  Seem reasonable?

	i'm not too sure, but mono_time is safer?  no?

itojun
Permalink | Reply | 31 comments |
headers
Simon Burge | 1 Aug 2002 06:18

Re: Trimming down pciide.o

On Wed, Jul 31, 2002 at 09:29:54PM +0200, Manuel Bouyer wrote:

> It's been some time that I noticed pciide.o is getting larger and
> larger. I'm planning splitting it up in different drivers (e.g.:
> piixide* at pci?
> viade* at pci?
> aceride* at pci?
> etc ...
> and a catch-all
> pciide* at pci?

Cool.  I'll junk my current patch then if you've got something different
in mind...

Simon.
--
Simon Burge                                   <simonb <at> wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/
Permalink | Reply | 0 comments |
headers
Simon Burge | 1 Aug 2002 06:25

Re: Culling a few calls to microtime()

On Thu, Aug 01, 2002 at 11:43:49AM +0900, itojun <at> iijlab.net wrote:

> >This is a little change to reduce a few calls to microtime() based on
> >some other similar code in the kernel.  Seem reasonable?
> 
> 	i'm not too sure, but mono_time is safer?  no?

microtime() operates on the "time" variable, not the "mono_time"
variable.  This is for timestamps only, so I think using the "time" is
better than using the unadjusted "mono_time" (which was the original
intent of using microtime() anyways).

Simon.
--
Simon Burge                                   <simonb <at> wasabisystems.com>
NetBSD Development, Support and Service:   http://www.wasabisystems.com/
Permalink | Reply | 0 comments |
headers
Jason R Thorpe | 1 Aug 2002 07:58

Re: Culling a few calls to microtime()

On Thu, Aug 01, 2002 at 11:43:49AM +0900, itojun <at> iijlab.net wrote:

 > >This is a little change to reduce a few calls to microtime() based on
 > >some other similar code in the kernel.  Seem reasonable?
 > 
 > 	i'm not too sure, but mono_time is safer?  no?

No, microtime returns results based on time, not mono_time, so using
time is more appropriate.

--

-- 
        -- Jason R. Thorpe <thorpej <at> wasabisystems.com>
Permalink | Reply | 29 comments |
headers
itojun | 1 Aug 2002 08:13

Re: Culling a few calls to microtime()

> > >This is a little change to reduce a few calls to microtime() based on
> > >some other similar code in the kernel.  Seem reasonable?
> > 	i'm not too sure, but mono_time is safer?  no?
>No, microtime returns results based on time, not mono_time, so using
>time is more appropriate.

	i was wondering if it has to monotonically increase or not.
	anyways, by using time we preserve the current behavior.

itojun
Permalink | Reply | 28 comments |
headers
Wojciech Puchar | 1 Aug 2002 11:26

Re: Trimming down pciide.o

>
> While looking at trimming down a kernel I noticed that one of the
> largest objects is pciide.o.  Since the particular board I was looking
> at only had a PIIX pciide controller, I've added some options so that we
> can select only a subset of all pciide controllers we support.
>
> As an example, adding:
>
> options         PCIIDE_RESTRICTED_SUPPORT # don't enable all pciide support
> options         PCIIDE_PIIX_ENABLE        # enable PIIX support
>
> to my kernel config results in pciide.o shrinking quite a lot:
>
> text    data    bss     dec     hex     filename
> 44752   80      0       44832   af20    pciide.o.before
> 13368   80      0       13448   3488    pciide.o.after
>
> What do people think of this?

while reducing kernel size of 30kB sounds good (and definitely it's worth
of work), reducing .data and .bss segment size of system libraries could
save such amount for EVERY process. for libc (x86):
 12 .data         0000212c  00080840  00080840  0007f840  2**5
 18 .bss          0000b060  00083660  00083660  00082660  2**5
                  ALLOC

15 pages total, possibly 16 as there are .got etc..

it doesn't make sense that minimal program take >64kB of unshared
memory.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wojciech Puchar | 1 Aug 2002 11:28

microtime

while seeing that discussion, and just need to measure precisely time in
my program...

what function can i use to measure elapsed time with precision like 10us.

i could have my machine unloaded and process on highest priority if it
help
Permalink | Reply | 27 comments |
headers
David Laight | 1 Aug 2002 12:08
Picon

Re: microtime

On Thu, Aug 01, 2002 at 11:28:23AM +0200, Wojciech Puchar wrote:
> what function can i use to measure elapsed time with precision like 10us.

gettimeofday() used the kernel microtime() function.
On i386 that gives a precision of about 1us.

	David

--

-- 
David Laight: david <at> l8s.co.uk
Permalink | Reply | 25 comments |
headers
Lord Isildur | 1 Aug 2002 16:14

Re: microtime

depending on what you need it for, recompile it with tracing, and then 
you get the ultimate timing precision, individual clock cycles. 
isildur

On Thu, 1 Aug 2002, Wojciech Puchar wrote:

> while seeing that discussion, and just need to measure precisely time in
> my program...
> 
> 
> what function can i use to measure elapsed time with precision like 10us.
> 
> i could have my machine unloaded and process on highest priority if it
> help
> 
>
Permalink | Reply | 0 comments |

Gmane