Subject: Re: diffs for UVM/UBC improvements available
To: Ben Harris <>
From: Chuck Silvers <>
List: tech-kern
Date: 05/22/2001 09:23:20
On Tue, May 22, 2001 at 03:32:30PM +0100, Ben Harris wrote:
> In article <> you write:
> >> as I was working on this stuff, I didn't really expect that it would have
> >> much affect on a more complex task like building a NetBSD snapshot.
> >> to my surprise, it does!  on my 400MHz pc, I see this improvement in
> >> "make build" performance:
> >> 
> >> -current:
> >> 4852.751u 779.388s 2:50:07.17 55.1%     0+0k 153979+322668io 42565pf+0w
> >> 
> >> with these diffs:
> >> 4855.911u 883.693s 2:29:39.24 63.9%     0+0k 16927+58502io 15800pf+0w
> >
> >oddly, cpu usage increases while walk-clock time decreases (and i/o
> >decreases dramatically).  do you have any understanding of why this is
> >the case?  
> It'd seem consistent with clustering I/O better.  This gives you relatively
> few large operations, instead of many small ones, and means the machine
> spends less time waiting for I/O, and hence a larger fraction of its time
> doing actual work.

this could be a reason, but the old code did a pretty good job of
i/o clustering, so that's probably not a significant factor here.

another reason for this increase is there's some stupid overhead involved
with mapping pages to do i/o (ie. pager_map).  this is necessary for now
since the device strategy interface requires that pages be mapped to perform
i/o on them.  once we change the disk i/o interfaces to not require this
any more, some of that system time will go away.  that's not going to happen
in time for NetBSD 1.6, though.

once the pager_map overhead is gone then I'll just run the whole build
under a profiling kernel and attack the problem that way.  that will show
me idle time too (since the idle loop shows up in the profiling data).

oh, there's actually more additional system time under UBC that doesn't show
up in "time" than there was in 1.5 (since the pagedaemon is actually doing
being run now, and aiodoned time is all new), so the real system time is
actually somewhat higher than this shows.