Re: asm/uaccess.h reimplementation, patch. [was: Re: 2.1 kernel bloat revisited]

Paul Gortmaker (paul@rasty.anu.edu.au)
Mon, 31 Mar 1997 02:05:08 +1000 (EST)


>
> > Just to see what access_ok() was responsible for (in terms of size)
> > I built two identical kernels with access_ok() defined to zero in one

[...]

> would be nice to see what speed difference it makes. I have the feeling
> that P5s see lots of pipeline stalls in access_ok().

While far from a P5, this is interesting information regardless.
Time to process a 270 page LaTeX document on a 386-40 (128k cache) with
5MB RAM, /usr and tex doc via NFS (kernel v2.1.30).

With access_ok() defined to "1".

------------------------------------------------------------------------
Memory: 4192k/5504k available (528k kernel code, 384k reserved, 400k data)

119.980u 77.100s 3:26.28 95.5% 0+0k 0+0io 139pf+0w
118.220u 75.850s 3:22.73 95.7% 0+0k 0+0io 129pf+0w
115.770u 76.050s 3:23.03 94.4% 0+0k 0+0io 131pf+0w
------------------------------------------------------------------------

With access_ok() doing what it is supposed to do:

------------------------------------------------------------------------
Memory: 4152k/5504k available (564k kernel code, 384k reserved, 404k data)

124.380u 109.470s 4:04.16 95.7% 0+0k 0+0io 187pf+56w
120.510u 111.490s 4:00.93 96.2% 0+0k 0+0io 142pf+0w
119.580u 109.490s 3:58.02 96.2% 0+0k 0+0io 133pf+0w
------------------------------------------------------------------------

Paul.