I'm running SuSE 9.2 on a Proliant DL380, was working fine, only had problems copy and entire tree from one FS to another (it seems to hang). The backup to tape was during 3 hours. The changes made (/boot/grub/menu.lst): * Deleted the "desktop" kernel parameter * Changed the "elevator" kernel parameter from "as" to "cfq" Now, the backups takes 1h 40 min to finish, any comments? Ciro
Ciro, On Monday 13 June 2005 19:57, Ciro Iriarte wrote:
I'm running SuSE 9.2 on a Proliant DL380, was working fine, only had problems copy and entire tree from one FS to another (it seems to hang). The backup to tape was during 3 hours. The changes made (/boot/grub/menu.lst):
* Deleted the "desktop" kernel parameter
I did this on my 9.1 system even though I am running a desktop system. In "desktop" mode the kernel's scheduling quantum is reduced by a factor of ten to create more responsiveness, but it increases scheduling overhead by the same factor. Given a fast enough CPU (3 GHz, in my case), this does not seem to impair perceived responsiveness. I'm not sure why, but my 9.3 installation did not include the "desktop" parameter. Maybe I removed it while installing and forgot doing so. Maybe it's no long enabled by default.
* Changed the "elevator" kernel parameter from "as" to "cfq"
This relates to how disk accesses are scheduled (ordered) when there are multiple outstanding I/O requests pending in the kernel disk queues. "CFQ" stands for "completely fair queuing" and "as" stands for "anticipatory scheduling". As the name suggests, the "anticipatory" scheduling has a stronger heuristic aspect and thus has more potential to be thwarted by access patterns not characteristic of the patterns it anticipates. The AS scheduler has several tunable parameters specific to it, too, so it's conceivable that there are values for those parameters that could give you even better performance than simply choosing CFQ. There's some explanatory text in "/usr/src/linux/Documentation/block/as-iosched.txt" and "/usr/src/linux/Documentation/kernel-parameters.txt" that you might be able to use to conduct some more directed, informed experiments.
Now, the backups takes 1h 40 min to finish, any comments?
There's no arguing with success, I'd say. At least in this case. I'd also venture to guess that these kernel parameters will _not_ lead to optimal performance during normal interactive or server loads and that you'll want to use them only for your backup purposes
Ciro
Randall Schulz
2005/6/14, Randall R Schulz
Ciro,
On Monday 13 June 2005 19:57, Ciro Iriarte wrote:
I'm running SuSE 9.2 on a Proliant DL380, was working fine, only had problems copy and entire tree from one FS to another (it seems to hang). The backup to tape was during 3 hours.
Maybe i could blame de reiserfs/hw raid5 combination for this..... (really didn't try it again after the change)
The changes made (/boot/grub/menu.lst):
* Deleted the "desktop" kernel parameter
I did this on my 9.1 system even though I am running a desktop system. In "desktop" mode the kernel's scheduling quantum is reduced by a factor of ten to create more responsiveness, but it increases scheduling overhead by the same factor. Given a fast enough CPU (3 GHz, in my case), this does not seem to impair perceived responsiveness.
I'm not sure why, but my 9.3 installation did not include the "desktop" parameter. Maybe I removed it while installing and forgot doing so. Maybe it's no long enabled by default.
Probably, but don't have 9.3 to test it...
* Changed the "elevator" kernel parameter from "as" to "cfq"
This relates to how disk accesses are scheduled (ordered) when there are multiple outstanding I/O requests pending in the kernel disk queues. "CFQ" stands for "completely fair queuing" and "as" stands for "anticipatory scheduling". As the name suggests, the "anticipatory" scheduling has a stronger heuristic aspect and thus has more potential to be thwarted by access patterns not characteristic of the patterns it anticipates. The AS scheduler has several tunable parameters specific to it, too, so it's conceivable that there are values for those parameters that could give you even better performance than simply choosing CFQ.
There's some explanatory text in "/usr/src/linux/Documentation/block/as-iosched.txt" and "/usr/src/linux/Documentation/kernel-parameters.txt" that you might be able to use to conduct some more directed, informed experiments.
Now, the backups takes 1h 40 min to finish, any comments?
There's no arguing with success, I'd say. At least in this case. I'd also venture to guess that these kernel parameters will _not_ lead to optimal performance during normal interactive or server loads and that you'll want to use them only for your backup purposes
Didn't notice any performance problems by now, and can't be playing with that machine. Maybe someone could/can make some tests and share what they found/find.
I took this from http://kerneltrap.org/node/3851 -------------------------------------------- - deadline scheduler: this is a cyclic elevator but with a twist: requests are given a deadline by which they get served. When a request starts to look like it's going to expire, the kernel will skip intermediate sectors and move to that request, thus giving some realtime behaviour. - AS scheduler: a cyclic elevator with waiting policy: after you service a request that looks like it might have future requests coming nearby, you pause even if there's more sectors in your work queue. The anticipatory scheduler literally anticipates more requests to follow on this track or very close by. How AS decides whether to anticipate is basically just lot of guesswork based on typical access patterns. - cfq scheduler: different sort of stab at fairness. It's different from either of these two, and doesn't use cyclic elevator and has realtime guarantees and aggressively avoids starvation. It could be a good scheduler for multiuser systems. - noop scheduler: just service next request in the queue without any algorithm to prefer this or that request. You want to use noop scheduler on devices where there are no seeking penalty, such as flash drives. That's why USB stick wants noop. Unfortunately, harddisks are very mechanial beasts and their performance is highly controlled by their seeking abilities. All these schedulers above are really trying to figure out how to extract maximum performance off the harddisk without causing bad behaviour in other cases. -----------------------------
Ciro
Randall Schulz
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Some tests with the new version of the CFQ Scheduler (i guess it's not included in 9.2) http://www.linode.com/forums/viewtopic.php?t=1330&start=0 Thanks, Ciro
2005/6/14, Randall R Schulz
Ciro,
On Monday 13 June 2005 19:57, Ciro Iriarte wrote:
I'm running SuSE 9.2 on a Proliant DL380, was working fine, only had problems copy and entire tree from one FS to another (it seems to hang). The backup to tape was during 3 hours. The changes made (/boot/grub/menu.lst):
* Deleted the "desktop" kernel parameter
I did this on my 9.1 system even though I am running a desktop system. In "desktop" mode the kernel's scheduling quantum is reduced by a factor of ten to create more responsiveness, but it increases scheduling overhead by the same factor. Given a fast enough CPU (3 GHz, in my case), this does not seem to impair perceived responsiveness.
I'm not sure why, but my 9.3 installation did not include the "desktop" parameter. Maybe I removed it while installing and forgot doing so. Maybe it's no long enabled by default.
* Changed the "elevator" kernel parameter from "as" to "cfq"
This relates to how disk accesses are scheduled (ordered) when there are multiple outstanding I/O requests pending in the kernel disk queues. "CFQ" stands for "completely fair queuing" and "as" stands for "anticipatory scheduling". As the name suggests, the "anticipatory" scheduling has a stronger heuristic aspect and thus has more potential to be thwarted by access patterns not characteristic of the patterns it anticipates. The AS scheduler has several tunable parameters specific to it, too, so it's conceivable that there are values for those parameters that could give you even better performance than simply choosing CFQ.
There's some explanatory text in "/usr/src/linux/Documentation/block/as-iosched.txt" and "/usr/src/linux/Documentation/kernel-parameters.txt" that you might be able to use to conduct some more directed, informed experiments.
Now, the backups takes 1h 40 min to finish, any comments?
There's no arguing with success, I'd say. At least in this case. I'd also venture to guess that these kernel parameters will _not_ lead to optimal performance during normal interactive or server loads and that you'll want to use them only for your backup purposes
Ciro
Randall Schulz
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
I noticed that SLES 9 comes with CFQ as the default scheduler CI.-
participants (2)
-
Ciro Iriarte -
Randall R Schulz