[lkml]   [1996]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: I/O request ordering

On Tue, 6 Aug 1996, Stephen C. Tweedie wrote:
> 5% seems an *awful* lot. There is a major problem with this sort of
> window, which is that fairness is sacrificed. It's not uncommon to
> have a lot of IO occurring at one part of the disk. The sawtooth
> guarantees that the request pointer will eventually move on to other
> requests. For example, take the case where there's a lot of syslog
> activity; you'll have a file being constantly written to disk via
> fsync, which can generate a lot of local write activity. You may
> starve the rest of the system if you don't limit the amount of
> backtracking allowed.

Yes. The problem is that we do need some kind of window, because I suspect
the current strict sawtooth algorithm is very bad indeed for demand-loading
executables. It's ok on an unloaded system, but executable loading time goes
_way_ up if you're doing anything else disk-intensive at the same time.
(Executable loading is hard, as the page-faults are totally synchronous. It
may make sense to give priority to page-faulting or something like that)

If somebody does test with new sorting algorithms, I'd suggest doing
something like

while true; do
grep "not really found anywhere" `find /usr/src/linux -type f`

in fact, do something like the above on _two_ separate Linux trees in
parallell, and then test how long it takes for programs to load etc "feel" of
the system. Make sure the source-tree (or whatever) you're grepping on is
larger than your physical memory, so that it doesn't work from the cache.


 \ /
  Last update: 2005-03-22 13:38    [W:0.055 / U:4.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site