# Can't compile the BFQ scheduler

## GSnake

Hello guys. I'm trying to compile the BFQ scheduler but it always ends this way:

```
make[1]: *** No rule to make target `block/bfq-iosched.o', needed by `block/built-in.o'.  Stop.

make: *** [block] Error 2

```

I've tried with both 3.4.9-gentoo and 3.5.3 (vanilla) sources...

I used these commands (the last kernel was 3.5.3): 

```
patch -p1 -i 0001-block-cgroups-kconfig-build-bits-for-BFQ-v4-3.5.patch
```

, 

```
patch -p2 -i 0002-block-introduce-the-BFQ-v4-I-O-sched-for-3.5.patch 

```

Any help is appreciated!

Thanks!

----------

## aCOSwt

1/ If you want to make things easy, you know that you get a 3.5.3 in the pf-sources which is supposed to work with the bfq.

2/ AFAIK the patches you are applying are the correct ones, please post the output of your patch commands.

BTW and sorry for this stupid question, are you sure that it is the budget fair queuing scheduler that you want ?

----------

## GSnake

 *aCOSwt wrote:*   

> 1/ If you want to make things easy, you know that you get a 3.5.3 in the pf-sources which is supposed to work with the bfq.
> 
> 2/ AFAIK the patches you are applying are the correct ones, please post the output of your patch commands.
> 
> BTW and sorry for this stupid question, are you sure that it is the budget fair queuing scheduler that you want ?

 

You're right. I'm dumb  :Sad: 

I meant the BFS! BTW I can't install it either (yeah, I tried to install the wrong one)... could you please guide me?

(I'm not choosing the pf-sources because I'd like to "understand" and learn more!)

----------

## aCOSwt

 *GSnake wrote:*   

>  *aCOSwt wrote:*   1/ If you want to make things easy, you know that you get a 3.5.3 in the pf-sources which is supposed to work with the bfq.
> 
> 2/ AFAIK the patches you are applying are the correct ones, please post the output of your patch commands.
> 
> BTW and sorry for this stupid question, are you sure that it is the budget fair queuing scheduler that you want ? 
> ...

 

I would have bet.

I don't think there are many people installing only the bfq.

OK then let's go with bfs.

1/ I strongly suggest you go there : https://bugs.gentoo.org/show_bug.cgi?id=434106

2/ Download the 2 files in attachement (Ebuild & patch)

3/ Put these into your local overlay... (If you need help for this I can be more precise)

4/ Emerge ck-sources-3.4.9

5/ Configure this kernel (about 3 CONFIG_XYZ only differ from a gentoo-sources .config)

And... Enjoy !

If you absolutely want a 3.5 then you'll have to wait for a week, I am a little bit busy now.

----------

## GSnake

Could you be more "noob-friendly"?  :Very Happy: 

Why can't I install it on my "vanilla" linux 3.5?

Could you please explain me both procedures? (For each kernel)

Thank you and sorry for bothering you!

----------

## aCOSwt

 *GSnake wrote:*   

> Could you be more "noob-friendly"? 
> 
> Why can't I install it on my "vanilla" linux 3.5?
> 
> Could you please explain me both procedures? (For each kernel)
> ...

 

1/ noob-friendliness : I thought I had been   :Confused: 

Noob-friendly under Gentoo, for me, means download the files & emerge.

Of course you can apply the patches by yourself using the patch command.

But then you'll be on your own and, depending on the kernel version you take, it might be not straightforward to understand from the traces of the patch command if the patch applied correctly or... created an horrible mess.

Morover, the CK patch is a single patch grouping the diffs of several files.

If beginners are willing to patch, great ! That is a good idea, but I would recommend starting by patching a single file of some application and not several files from the kernel...   :Twisted Evil: 

2/ If you still want to proceed that way... you are warmly welcome :

Assuming you have downloaded the ck-patches then

a/ unzip it with bunzip2 in the base directory of your unpatched kernel

b/ patch --dry-run -p1 < patchname (the dry-run option being a good idea in order to see what is going to be done without actually doing it)

c/ read and understand the traces that patch will output together with the man page of patch. (pay a particular attention to all lines starting with HUNK).

All of them highlight the fact that you are not patching the exact same version of the kernel that the one CK worked with => This will or will not create troubles (when building / linking / at run time) even if the patch command works correctly.

d/ I you are happy, redo the same command removing the --dry-run.

Good luck !

If you prefer the emerge way, (much simpler and already tested by others) I'll tell you.

----------

## GSnake

Almost done!

(I'm trying the hard way as always, it's funnier!)

Thank you! 

If I subtract 90° to you, would you become aSINwt?  :Very Happy: 

----------

## aCOSwt

 *GSnake wrote:*   

> Almost done!

 

Congratulations !

 *GSnake wrote:*   

> If I subtract 90° to you, would you become aSINwt? 

 

I fear it is not absolutely legal to substract 90° from aCOSwt.   :Razz: 

So I guess you mean subtracting Π/2 from wt.

Yes, that's me when I was young...er !   :Twisted Evil: 

----------

## GSnake

DONE! Compiled!

But one last thing: I can't understand if I'm currently running with the BFS scheduler since I can't check it in the menuconfig: while the BFQ scheduler had the "block devices" option, BFS hasn't got that option. It's located in the general settings... what should I do?

PS: MY BAD! Acos(wt - 90°)  :Wink: 

----------

## aCOSwt

In the base directory of your kernel :

Check the status of CONFIG_SCHED_BFS in your .config.

If you can read CONFIG_SCHED_BFS=y AND you built your kernel normally with make... etc and updated your bootloader config file and copied bzImage in /boot... etc... and reboot

Then you are indeed running the BFS.

In order to be dead sure then you can check (under a BFSized kernel active) for the existence of /proc/sys/kernel/rr_interval

(This is a tuneable for bfs)

----------

## GSnake

 *aCOSwt wrote:*   

> In the base directory of your kernel :
> 
> Check the status of CONFIG_SCHED_BFS in your .config.
> 
> If you can read CONFIG_SCHED_BFS=y AND you built your kernel normally with make... etc and updated your bootloader config file and copied bzImage in /boot... etc... and reboot
> ...

 

Done all that but /proc/sys/kernel/rr_interval doesn't exist...  :Sad: 

[/code]

----------

## aCOSwt

 *GSnake wrote:*   

>  *aCOSwt wrote:*   In the base directory of your kernel :
> 
> Check the status of CONFIG_SCHED_BFS in your .config.
> 
> If you can read CONFIG_SCHED_BFS=y AND you built your kernel normally with make... etc and updated your bootloader config file and copied bzImage in /boot... etc... and reboot
> ...

 

Then I am afraid your system is not running BFS.

Can you (un)confirm each of the following steps :

1/ Your /usr/src/linux symlink correctly points to the base directory of the kernel you patched.

If not : eselect kernel set accordingly and restart making your kernel

2/ You can read CONFIG_BFS_SCHED in /usr/src/linux/.config

If not then the patch did not apply correctly : post the output of your patch command

3/ You can read CONFIG_BFS_SCHED=y in /usr/src/linux/.config

If not then if yes to 2 then you must read : # CONFIG_BFS_SCHED is not set

In which case then make menuconfig and set the BFS scheduler option and rebuild your kernel

4/ While in the /usr/src/linux, make sure make && make modules_install successfully completed (Read the 5 or so last lines) and re crosscheck if the timestamp of /usr/src/linux/yourarch/boot/bzImage is coherent

If not then the build of your kernel failed => Provided you worked on a clean official vanilla, (I mean not already polluted by other clumsy tries of patching   :Wink:  ) this means that the patch command ran correctly but, as I wrote in a previous post, what you patched created some mess in the kernel's code.

In which case, either you understand the mess done and can correct it or => Chose a lower version for your base kernel.   :Twisted Evil: 

5/ If everything is OK then... you missed something in the standard procedure of installing a new kernel.

----------

## GSnake

It's working now! I forgot to symlink the kernel... but, since I'm new... what does "symlinking" do? Why it's so important?

----------

## aCOSwt

The symbolic link simply enables to coherently refer to the base directory of the kernel you are working on with a single and unique name.

=> In the documentation, you can read references to /usr/src/linux which is far more understandable than /usr/src/whatever_the_name_of_the_base_directory_of_the_kernel_you_are_working_on...   :Laughing: 

But much more importantly, when building some out-of-kernel drivers (video proprietary drivers...) or a couple of other packages in portage, the build process will need to link with, include files belonging to the kernel. The build process will look for those files in /usr/src/linux. => /usr/src/linux must reference the base directory of a valid kernel distribution.

In addition to this, there are a couple of system utilities (ps as an example) which do not really like when your symbolic link does not point to your currently active kernel.

----------

## GSnake

Perfect! Thanks!

----------

