Simon Burge | 1 Aug 03:26 2002

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)

itojun | 1 Aug 04:43 2002
Picon

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

Simon Burge | 1 Aug 06:18 2002

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/

Simon Burge | 1 Aug 06:25 2002

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/

Jason R Thorpe | 1 Aug 07:58 2002

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>

itojun | 1 Aug 08:13 2002
Picon

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

Wojciech Puchar | 1 Aug 11:26 2002
Picon

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)

Wojciech Puchar | 1 Aug 11:28 2002
Picon

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

David Laight | 1 Aug 12:08 2002
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

Lord Isildur | 1 Aug 16:14 2002

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
> 
> 


Gmane