# Best scheduler for SSD

## albright

I'm in the process of install gentoo on a lenovo x300 (right

now, 77 of 207 emerged for kdebase-meta  :Smile:  ).

So I've got some time to think and - as in the subject - I

wonder what the boffins here think is the best io scheduler

for SSDs? A rough survey of google suggests noop is the

winner, but I haven't found much test evidence.

What do people think?

[Edit: hmmm, maybe this should be in gentoo chat - please

move if appropriate]

----------

## alex.blackbit

actually a quite good question. unfortunately i do not have a good answer for you.   :Evil or Very Mad: 

but it should be quite easy to benchmark that.

just add elevator= to your grub boot options and choose one of {noop,deadline,cfq,as}, giving that you have all of those available.

you can also change it during runtime with

```
echo <sched_algorithm> > /sys/block/<disk>/queue/scheduler
```

measuring the needed time for a portage tree sync in an empty directory should be good enough to see which one works better.

the results would be interesting.

----------

## cruzki123

I remember that I did a benchmark test on my acer aspire one. I Took a stopwatch and time from grub to kdm. If I remeber well:

cfq around 30 s

noob around 20 s

In other areas I don't know :S

----------

## alex.blackbit

well, i do not think that the boot process is a very good benchmark for a I/O scheduler.

but it is interesting that the difference is so significant.

----------

## albright

I twice synced to an empty portage directory (may the lords of gentoo

forgive me  :Smile:  ) and there was no difference to speak of (just a few

seconds. The time was about real: 7.5 minutes, user 7.5 seconds and

sys 7 minutes for both. I suspect this is not a very good test.

I've left it with noop for the moment. In general, the machine is very

impressive. After boot up, startx gets kde4.2 to a useable desktop

in less than 10 seconds.

----------

## zyko

 *Quote:*   

> I suspect this is not a very good test.

 

It's a bad test. Schedulers come into action when there is a queue of I/O operations. A simple example would be if you caused multiple transfers at the same time on the same hard drive. The scheduler would then decide which transfer to execute first, since the assumption is that no hard drive can do more than exactly one thing at once.

Schedulers have been designed with the assumption in mind that HDDs have significant mechanical latencies and that schedulers must somehow queue all I/O operations in such a way as to minimize the mechanical movement of the HDD parts. SSDs don't work like that at all. They have no mechanical latencies to speak of. Scheduling algorithms applied to SSDs would probably not improve anything and cause useless overhead. Therefore, most people should go for no-op (no scheduling at all).

----------

## 96140

--Last edited by 96140 on Wed Sep 11, 2013 8:51 am; edited 1 time in total

----------

## i92guboj

 *nightmorph wrote:*   

> You should use noop with that SSD.
> 
> Source: Tweaking SSDs for Linux. There's a lot of other good stuff in the article, so be sure to read the rest.

 

I agree with this. There's no seek involved, so reordering the i/o operations makes no sense. Its the same basic principle that renders fragmentation in these devices pointless. For the device is exactly the same to access blocks 1, 17, 6 than to access 1, 6, 17, simplistic generalization but you get the idea.

----------

## albright

thanks for the link, nightmorph

I've been using noop since I installed gentoo and it has

been very satisfactory. The machine boots into the kde4.2

desktop in 20 seconds from grub menu (30 seconds from

power on - the initialization seems slow to me).

I'm not sure about removing the journal - setting my x300

up I've had some lockups and freezes and it *might* be

that the journal has saved my butt - it certainly has sped

up reset reboots. Maybe once the machine is "stable" I'll

start mounting ext2.

thanks again

----------

