Long ago, it was written here on 25 Oct 2000 by Matt Dillon:
> :Consider that a file with a huge number of pages outstanding
> :should probably be stealing pages from its own LRU list, and
> :not the system, to satisfy new requests. This is particularly
> :true of files that are demanding resour
> :> Personally speaking, I would much rather use MAP_NOSYNC anyway,
> even with
> :...
> :Everything starts out well, where the history disk is beaten at startup
> :but as time passes, the time taken to do lookups and writes drops down
> :to near-zero levels, and the disk gets quiet. And act
> :but at last look, history lookups and writes are accounting for more
> :than half (!) of the INN news process time, with available idle time
> :being essentially zero. So...
>
> No idle time? That doesn't sound like blocked I/O to me, it sounds
> like the machine has run out of cpu.
> ok, since I got about 6 requests in four hours to be Cc'd, I'm
> throwing this back onto the list. Sorry for the double-response that
> some people are going to get!
Ah, good, since I've been deliberately avoiding reading mail in an
attempt to get something useful done in my last
Howdy,
I'm going to breach all sorts of ethics in the worst way by following
up to my own message, just to throw out some new info... 'kay?
Matt wrote, and I quote --
: > However, I noticed something interesting!
Of course I clipped away the interesting Thing, but note the following
that I saw
> :The mlock man page refers to some system limit on wired pages; I get no
> :error when mlock()'ing the hash file, and I'm reasonably sure I tweaked
> :the INN source to treat both files identically (and on the other machines
> :I have running, the timestamps of both files remains pretty much unc
6 matches
Mail list logo
