mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Bráulio Barros de Oliveira" <brauliobo@gmail.com>
To: Mat <jackdachef@gmail.com>
Cc: reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Re: reiserfs do_journal_end unnecessary hd wake up?
Date: Thu, 4 Sep 2008 19:38:56 -0300	[thread overview]
Message-ID: <1df1788c0809041538x8d41eb8s80966f25aa2ade21@mail.gmail.com> (raw)
In-Reply-To: <loom.20080904T211127-782@post.gmane.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 3583 bytes --]

thank you very much for the great instructions. i'll evaluate then andsend you the results.bráulio
On Thu, Sep 4, 2008 at 6:16 PM, Mat <jackdachef@gmail.com> wrote:> ok, then try the following:>> you at least should have noatime,nodiratime,commit=600>> enabled for the reiserfs or >=ext3 filesystems>> you can also try data=writeback (but beware this might put your data at risk !)>>> select the anticipatory i/o scheduler> and set following stuff>> echo "16" > /proc/sys/vm/page-cluster> # default: 3> #>> echo "60" > /proc/sys/vm/swappiness> # default: 60> # By default, Linux will aggressively swap processes out of physical memory onto> disk in order to keep the disk cache as large as possible.> # This means that pages that haven't been used recently will be pushed into swap> long before the system even comes close to running out of memory, which is an> unexpected behavior compared to some operating systems.> # The /proc/sys/vm/swappiness parameter controls how aggressive Linux is in this> area.>> echo "3000" > /proc/sys/vm/dirty_expire_centisecs> # default: 3000 (30 seconds)> #2 how long data can be in the page cache before it is considered expired and> must be written at the next opportunity. Note that this default is very long: a> full 30 seconds. That means that under normal circumstances, unless you write> enough to trigger the other pdflush method, Linux won't actually commit anything> you write until 30 seconds later.>> echo "6000"  > /proc/sys/vm/dirty_writeback_centisecs> # default: 500 (5 seconds)> #1 how often pdflush wakes up to write data to disk. The default wakes up the> two (or more) active threads every five seconds.> # suggestion: 6000 (every 60 seconds)>> echo "15" > /proc/sys/vm/dirty_background_ratio> # default: 10> #3 Maximum percentage of active memory that can be filled with dirty pages> before pdflush begins to write them>> echo "50"   > /proc/sys/vm/dirty_ratio #modified> # default: 40> #4 Maximum percentage of total memory that can be filled with dirty pages before> processes are forced to write dirty buffers themselves during their time slice> instead of being allowed to do more writes.> # modified: 50>> echo "25" > /proc/sys/vm/vfs_cache_pressure>> for i in /sys/block/sd*; do>         /bin/echo "anticipatory" >  $i/queue/scheduler> done>> for i in /sys/block/sd*; do>         /bin/echo "0" >  $i/queue/iosched/antic_expire> done>> for i in /sys/block/sd*; do>         /bin/echo "150" >  $i/queue/iosched/read_expire> done>> for i in /sys/block/sd*; do>         /bin/echo "750" >  $i/queue/iosched/read_batch_expire> done>> for i in /sys/block/sd*; do>         /bin/echo "1200" >  $i/queue/iosched/write_batch_expire> done>> for i in /sys/block/sd*; do>         /bin/echo "1024" >  $i/queue/nr_requests> done>> for i in /sys/block/sd*; do>         /bin/echo "256" >  $i/queue/read_ahead_kb> done>> for i in /sys/block/sd*; do>         /bin/echo "256" >  $i/queue/max_sectors_kb> done>> for i in /sys/class/scsi_host/host*; do>         /bin/echo "min_power" >  $i/link_power_management_policy> done>>>>> try to disable each and every unneeded daemon or applets, programs, etc.>> by using:>> * powertop> * iotop> * htop> * top> * lsof | grep /home> * ...>>>> --> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in> the body of a message to majordomo@vger.kernel.org> More majordomo info at  http://vger.kernel.org/majordomo-info.html>ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

       reply	other threads:[~2008-09-04 22:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <loom.20080904T211127-782@post.gmane.org>
2008-09-04 22:38 ` Bráulio Barros de Oliveira [this message]
2008-09-04 23:28   ` Bráulio Barros de Oliveira
2008-09-04 23:32     ` Bráulio Barros de Oliveira
2008-09-04 23:47       ` Bráulio Barros de Oliveira
     [not found]         ` <200809050154.00318.volker.armin.hemmann@tu-clausthal.de>
2008-09-04 23:59           ` Bráulio Barros de Oliveira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1df1788c0809041538x8d41eb8s80966f25aa2ade21@mail.gmail.com \
    --to=brauliobo@gmail.com \
    --cc=jackdachef@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reiserfs-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®