faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
Re: Queued tasks
by anonymous on Tuesday 23/Jan/2007, @23:45
|
you are wrong. although the elevator algorithm is rather good, you will still loose a lot of performance when copying two sequential files. reason being that for a single sequential file copy there is no seek time at all and the seek time is significantly larger than the time it takes to read a whole cylinder (ie. multiple sectors).
this problem becomes more significant as hdd size increases. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Queued tasks
by superstoned on Wednesday 24/Jan/2007, @03:55
|
with a modern (>2.6.18) linux kernel and using the (default) CFQ scheduler, the performance difference will be very small (eg a few % max). so, not to worry about.
|
[
Reply To This | View ]
|
Re: Queued tasks
by giu73 on Wednesday 24/Jan/2007, @10:02
|
Can you expand on this? I don't really know how CFQ works, but, the "Fair" in its name makes me think that it would not be the best choice for this scenario. Basically, we have two large tasks, with a very high switching cost between the two. To optimize performance, we should minimize the number of switches, that is serving each task for a very long time interval before switching to the other (the best being serving one task until it is completely finished and then going to the other). This does not sound "Fair", to me.
|
[
Reply To This | View ]
|
Re: Queued tasks
by superstoned on Wednesday 24/Jan/2007, @10:21
|
but it is what CFQ does, both ensuring task interactivity AND increasing throughput. compared to the previous kernel scheduler, cfq uses longer timeslices, but has some logic to ensure reads don't slow down, and there are maximum waits for apps who want to read and write data.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|