All of lore.kernel.org
 help / color / mirror / Atom feed
From: "JaniD++" <djani22@dynamicweb.hu>
To: "Roger Heflin" <rheflin@atipa.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: buffer cache question
Date: Tue, 22 Nov 2005 01:41:22 +0100	[thread overview]
Message-ID: <00ad01c5eefd$7990b370$a700a8c0@dcccs> (raw)
In-Reply-To: EXCHG2003iSnRMWuLn500000618@EXCHG2003.microtech-ks.com

Hi,

I have read back in the kernel-archives, and found this messages, about the
same theme, but there is one difference!

On the old messages:
>Nate Diller wrote:
> just found the culprit.  guess i should have read the code the first
> time.  get_dirty_limits() in drivers/block/page_writeback.c has a
> hard-coded upper limit to dirty_ratio.  it's capped to half of the
> unmapped pages, so maybe 30-40% of your system's memory.  so if you are
> brave, just remove the "/ 2" parts from the 'if (dirty_ratio >
> unmapped_ratio / 2) dirty_ratio = unmapped_ratio / 2;' check, and you
> can have all the OOM goodness you want.
...
>I changed that bit of code to:
>
> if (dirty_ratio > unmapped_ratio - 10)
>  dirty_ratio = unmapped_ratio - 10;
>
>and added a couple of sanity checks so that it couldn't get below 5 or
above 95.
>
>Then set /proc/sys/vm/dirty_ratio to 95 and dirty_background_ratio to 1.

In this case, this modification is only for the *dirty* memory buffer.
I want to use more buffer *cache*! :-)
The unwritten dirty memory ratio is good enough for me.

Anybody has an idea?

Cheers,
Janos

----- Original Message ----- 
From: "Roger Heflin" <rheflin@atipa.com>
To: "'JaniD++'" <djani22@dynamicweb.hu>; <linux-kernel@vger.kernel.org>
Sent: Monday, December 19, 2005 7:15 PM
Subject: RE: buffer cache question


>
>
> > -----Original Message-----
> > From: linux-kernel-owner@vger.kernel.org
> > [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of JaniD++
> > Sent: Sunday, December 18, 2005 3:09 PM
> > To: linux-kernel@vger.kernel.org
> > Subject: buffer cache question
> >
> > Hello, list,
> >
> > I use 4 disk nodes with NBD.
> > All of my nodes have 2GB ram.
> >
> > But the buffer cache newer rise over 830MB.
> >
> > Is there some limit?
>
> For writes only 40% of the ram can be "dirty".
>
> > Where can i change this limit? (if it is)
>
> I believe there is a way to change it, I am pretty sure that it has
> been discussed on the kernel list a couple of months ago, I
> don't remember exactly what the change is, and I think the change
> was more complicated that was obvious.
>
> The previous subject on a similar thing was:
> "kernel 2.6.13 buffer strangeness"
>
>                            Roger
>
> >
> > Thanks,
> > Janos
> >
> > [root@st-0001 root]# free
> >              total       used       free     shared
> > buffers     cached
> > Mem:       2073152     933188    1139964          0
> > 836776      43416
> > -/+ buffers/cache:      52996    2020156
> > Swap:            0          0          0
> > [root@st-0001 root]# cat /proc/meminfo
> > MemTotal:      2073152 kB
> > MemFree:       1139012 kB
> > Buffers:        835928 kB
> > Cached:          43448 kB
> > SwapCached:          0 kB
> > Active:          12872 kB
> > Inactive:       871424 kB
> > HighTotal:     1179584 kB
> > HighFree:      1129764 kB
> > LowTotal:       893568 kB
> > LowFree:          9248 kB
> > SwapTotal:           0 kB
> > SwapFree:            0 kB
> > Dirty:               0 kB
> > Writeback:           0 kB
> > Mapped:           9104 kB
> > Slab:            30248 kB
> > CommitLimit:   1036576 kB
> > Committed_AS:    15428 kB
> > PageTables:        408 kB
> > VmallocTotal:   114680 kB
> > VmallocUsed:       196 kB
> > VmallocChunk:   114476 kB
> > [root@st-0001 root]#
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-kernel" in the body of a message to
> > majordomo@vger.kernel.org More majordomo info at
> > http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


  reply	other threads:[~2005-12-21  0:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-18 21:09 buffer cache question JaniD++
2005-12-19 18:15 ` Roger Heflin
2005-11-22  0:41   ` JaniD++ [this message]
     [not found]     ` <5c49b0ed0512230058q157ddedx96059d876c45a69f@mail.gmail.com>
2005-12-23 21:50       ` JaniD++
2005-12-29  4:10         ` Nate Diller
2005-12-29 16:26           ` JaniD++

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='00ad01c5eefd$7990b370$a700a8c0@dcccs' \
    --to=djani22@dynamicweb.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rheflin@atipa.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.