BFQ: simple elevator

[Matthias Brugger]

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