Revision history [back]

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. There is an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su
<your password>

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. There is an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su
<your password>

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. There is an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su
<your password>

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. There Using this, my phone performs a btrfs balance in the background without any performance impact at all.There is an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all.There is an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all.There all. There is an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. There is It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before beginning changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

echo deadline > /sys/block/mmcblk1/queue/schedule
/sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire
 

If you have an sd-card in your phone, enter the same for mmcblk1 to make it more responsive too:

echo deadline > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but I in my experience, the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

If you have an sd-card in your phone, enter the same for mmcblk1 to make it more responsive too:

echo deadline > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but in my experience, experience the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

If you have an sd-card in your phone, enter the same for mmcblk1 to make it more responsive too:

echo deadline > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but in my experience the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. scheduler. Mainly I prefer the deadline scheduler because it guarantees responsiveness when there are large operations going on (such as btrfs balance), and for me responsiveness is more important than shaving a few percent off total execution time (I hate it when I get jitter and lag). [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

If you have an sd-card in your phone, enter the same for mmcblk1 to make it more responsive too:

echo deadline > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.

If you are having problems with the phone becoming laggy or unresponsive during heavy disk IO (downloading/installing many or large packages, running btrfs balance, etc) this is for you. Using this, my phone performs a btrfs balance in the background without any performance impact at all. It is done by an easy kernel tweak to the disk scheduler that gives much better flash-storage responsiveness during heavy disk IO.

[background] The default disk scheduler is optimized for spinning disks. It tries to batch together transfers so that it runs as long a sequence of sectors as possible before changing to another transfer. This is because shifting back and forth between different disk locations (a seek operation) is extremely slow on a spinning disk. The disadvantage is that two simultaneous transfers do not "share bandwidth"; one transfer will hog the disk for a considerable time, locking all other transfers in queue.

With flash, the penalty for a seek operation is negligible, and several transfers can easily take turns accessing the disk, rapidly changing back and forth between all simultaneous transfers. That way all tasks immediately get to do their disk IO without waiting for large transfers to complete and the phone feels much more responsive during large disk operations.

There are three schedulers to choose from in the Jolla kernel, the default "cfq" scheduler, the "deadline" scheduler and the "noop" scheduler. The deadline scheduler attempts to guarantee the next transfer in queue to get a time-slice within a certain time, giving real-time constraints. The noop scheduler simply doesn't schedule at all. I have seen many recommend the noop scheduler for flash, but in my experience the deadline scheduler, in particular with tighter time-constraints than default, gives better results than the noop scheduler. Mainly I prefer the deadline scheduler over the noop scheduler because it guarantees responsiveness when there are large operations going on (such as btrfs balance), and for me responsiveness is more important than shaving a few percent off total execution time (I hate it when I get jitter and lag). [/background]

Howto:

Make sure you have developer mode active on your phone, then enter:

devel-su

your password

echo deadline > /sys/block/mmcblk0/queue/scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk0/queue/iosched/read_expire
echo 50 > /sys/block/mmcblk0/queue/iosched/write_expire

If you have an sd-card in your phone, enter the same for mmcblk1 to make it more responsive too:

echo deadline > /sys/block/mmcblk1/queue/scheduler
echo 1 > /sys/block/mmcblk1/queue/iosched/fifo_batch
echo 10 > /sys/block/mmcblk1/queue/iosched/read_expire
echo 50  > /sys/block/mmcblk1/queue/iosched/write_expire

You can put that in a script and run from your startup if you don't want to re-enter every time you reboot the phone.