[lkml]   [2003]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.5.59-mm5
"Luck, Tony" <> wrote:
> Andrew Morton wrote:
> So what anticipatory scheduling does is very simple: if an application
> has performed a read, do *nothing at all* for a few milliseconds. Just
> return to userspace (or to the filesystem) in the expectation that the
> application or filesystem will quickly submit another read which is
> closeby.
> Do you need to give a process being woken from the read an extra priority
> boost to make sure that it actually gets run in your "few milliseconds"
> window. It would be a shame to leave the disk idle for the interval, and
> then discover that the process scheduler had been running other stuff, so
> that the reader didn't get a chance to issue the next read.

Indeed. I have experimented with giving the to-be-woken task a boost in the
CPU scheduler, and was not able to observe much difference. At the very
least, one would expect to be able to decrease the anticipation timeout with
that in place.

Maybe it just needs more testing to find the usage patterns which need this

It could be that the woken task is getting sufficient boost from the
effective_prio() logic that no change will be needed. I don't know yet.

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

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