Re: [RFC] Optimization for use-once pages

From: Patrick Dreker (
Date: Wed Jul 25 2001 - 03:20:49 EST

Am Mittwoch, 25. Juli 2001 02:27 schrieb Linus Torvalds:
> On Tue, 24 Jul 2001, Rik van Riel wrote:
> > (using smaller chunks, or chunks which aren't a
> > multiple of 4kB should break the current code)
> Maybe Patrick is using stdio? In that case, the small chunks will be
> coalesced in the library layer anyway, which might explain the lack of
> breakage.
I am using normal read() calls to read the file after open()ing it on program
start and each call reads only 4 bytes. So if I am reading this right I am
seeing an improvement where I should not see one, or at least not such a big
one, right?

I did a few more test runs on each of the kernels to check if the results are
17.320u 115.100s 2:17.36 96.4% 0+0k 0+0io 110pf+0w
17.200u 94.170s 1:53.14 98.4% 0+0k 0+0io 110pf+0w
17.490u 113.730s 2:13.48 98.3% 0+0k 0+0io 110pf+0w

14.730u 108.310s 2:09.57 94.9% 0+0k 0+0io 203pf+0w
13.880u 79.410s 1:38.64 94.5% 0+0k 0+0io 226pf+0w
14.840u 78.680s 1:37.86 95.5% 0+0k 0+0io 238pf+0w

The time under 2.4.5-use_once stays constant from the second run on (I tried
3 more times), while 2.4.7 shows pretty varying performance but I have never
seen it getting better than the 1:53.14 from the second run above. I had
stopped all services which I knew to cause periodic activity (exim,
cron/anacron) which could disturb the tests.

I also noticed, that under 2.4.5 after the 3 test runs the KDE Taskbasr got
swapped out, while under 2.4.7 this was not the case.

> Of course, if it improved performance even when "broken", that would be
> even better. I like those kind sof algorithms.
Who doesn't? :)

> Linus

Patrick Dreker
> Is there anything else I can contribute?
The latitude and longtitude of the bios writers current position, and
a ballistic missile.        
                         Alan Cox on
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Tue Jul 31 2001 - 21:00:21 EST