<div bgcolor="#FFFFFF" text="#000000">
<div>On 03/23/2013 01:05 AM, Raymond
Jennings wrote:<br>
</div>
<blockquote type="cite">
<pre>On Fri, Mar 22, 2013 at 2:20 PM, <a href="mailto:Valdis.Kletnieks@vt.edu" target="_blank"><Valdis.Kletnieks@vt.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre>On Fri, 22 Mar 2013 13:53:45 -0700, Raymond Jennings said:
</pre>
<blockquote type="cite">
<pre>The first heap would be synchronous requests such as reads and syncs
that someone in userspace is blocking on.
The second is background I/O like writeback and readahead.
The same distinction that CFQ completely makes.
</pre>
</blockquote>
<pre>Again, this may or may not be a win, depending on the exact workload.
If you are about to block on a userspace read, it may make sense to go ahead
and tack a readahead on the request "for free" - at 100MB/sec transfer and 10ms
seeks, reading 1M costs the same as a seek. If you read 2M ahead and save 3
seeks later, you're willing. Of course, the *real* problem here is that how
much readahead to actually do needs help from the VFS and filesystem levels -
if there's only 600K more data before the end of the current file extent, doing
more than 600K of read-ahead is a loss.
Meanwhile, over on the write side of the fence, unless a program is
specifically using O_DIRECT, userspace writes will get dropped into the cache
and become writeback requests later on. So the vast majority of writes will
usually be writebacks rather than syncronous writes.
So in many cases, it's unclear how much performance CFQ gets from making
the distinction (and I'm positive that given a sufficient supply of pizza and
caffeine, I could cook up a realistic scenario where CFQ's behavior makes
things worse)...
Did I mention this stuff is tricky? :)
</pre>
</blockquote>
<pre>Oh I'm well aware that it's tricky. but as I said i'm more interested
in learning the api than tuning performance.
Having a super efficient toaster won't do much good if I can't plug
the darn thing in.</pre>
</blockquote>
<br>
If you want to understand the interface, I would recommend to start
having a look to the noop scheduler. It's by far the simplest
implementation of a scheduler.<br>
<br>
For me a good starting point were this slides:<br>
<a href="http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20IO%20Schedulers.pdf" target="_blank">http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20IO%20Schedulers.pdf</a><br><br>Hope that helps you to bring the theory into practice :)<br>
<br>
<blockquote type="cite">
<pre>_______________________________________________
Kernelnewbies mailing list
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a>
</pre>
</blockquote>
<br>
</div>