BFQ: simple elevator

[Raymond Jennings]

it would appear indeed that my primitive "out of my hat" is identical to LOOK.

On Mon, Mar 25, 2013 at 3:27 PM, Matthias Brugger
<matthias.bgg at gmail.com> wrote:
> 2013/3/25 Raymond Jennings <shentino at gmail.com>:
>> On Sat, Mar 23, 2013 at 9:42 AM, Matthias Brugger
>> <matthias.bgg at gmail.com> wrote:
>>> On 03/23/2013 01:05 AM, Raymond Jennings wrote:
>>>
>>> On Fri, Mar 22, 2013 at 2:20 PM,  <Valdis.Kletnieks at vt.edu> wrote:
>>>
>>> On Fri, 22 Mar 2013 13:53:45 -0700, Raymond Jennings said:
>>>
>>> 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.
>>>
>>> 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? :)
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>
>>> For me a good starting point were this slides:
>>> http://www.cs.ccu.edu.tw/~lhr89/linux-kernel/Linux%20IO%20Schedulers.pdf
>>>
>>> Hope that helps you to bring the theory into practice :)
>>>
>>> _______________________________________________
>>> Kernelnewbies mailing list
>>> Kernelnewbies at kernelnewbies.org
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>
>> Just what I was looking for.
>>
>> Now, how do I enable/disable my scheduler during kernel config?
>
> 1. Add your disk scheduler to the kernel sources (Kconfig, Makefile
> and in block/bfq-iosched.c)
> 2. Add the bfq scheduler in the kernel config (as a moudle might make sense)
> 3. Recompile and install your new kernel
> 4. You can load/unload the module dynamically. Via sysfs you can
> associate the bfq scheduler with one disk.
>
> Happy hacking :)
>
> --
> ---
> motzblog.wordpress.com