Am 03.01.2014 15:07, schrieb Alan McKinnon: > On 03/01/2014 15:13, William Kenworthy wrote: >> On 03/01/14 15:34, Alan McKinnon wrote: >>> On 03/01/2014 09:25, Stefan G. Weichinger wrote: >>>> Am 03.01.2014 07:52, schrieb Alan McKinnon: >>>>> On 03/01/2014 00:46, Stefan G. Weichinger wrote: >>>>>> BFQ only for the SSDs ? >>>>> >>>>> Yes. The scheduler knows how to deal with SSDs while keeping everything >>>>> responsive even under load. >>>>> >>>>> BFQ seems a good fit for your workcase - desktop/laptop. For those, >>>>> interactive performance is the most important thing. >>>> >>>> So you set BFQ for the SSDs and CFQ for the hdds ? I have both in my >>>> desktop. >>>> >>>> >>>> >>>> >>> >>> BFQ for both is the recommendation. >>> >>> But do try it both ways to see how it performs and compare. >>> >> >> hmm, is BFQ good for VM's too? I am currently using noops (storage is >> ceph) and was going to experiment but have not had the time yet. > > > I have no idea, but I'd like to find out. > > Instinct tells me one of the host or guest should be NOOP so that the > other one can get on with scheduling without conflict. But I also reckon > the question is waaaay more complex than that. A VM should always use noop, as it doesn't know about the physical layout of the disk (except if you did pass the devices card through... with a SAS interface over PCIe for example). What IO-scheduler you'd use for the host depends on your hardware and the desired optimization goal (throughput vs latency).
My _personal_ opinion for the desktop(!): If you're content with the general performance I would not optimize for your most common use case (global maximum), but for the use case that is not-to-uncommon and that benefits most of it. The idea is, that if most of you life is good, try to make the remaining part suck less :) Greetings, Daniel
signature.asc
Description: OpenPGP digital signature
