linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Tomasz Chmielewski <mangoo@wpkg.org>
Cc: linux-mm@kvack.org
Subject: Re: why my systems never cache more than ~900 MB?
Date: Wed, 25 Mar 2009 02:42:35 +1100	[thread overview]
Message-ID: <200903250242.35787.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <49C8FDD4.7070900@wpkg.org>

On Wednesday 25 March 2009 02:35:48 Tomasz Chmielewski wrote:
> Nick Piggin schrieb:
> > On Tuesday 24 March 2009 19:42:08 Tomasz Chmielewski wrote:
> >> On my (32 bit) systems with more than 1 GB memory it is impossible to
> >> cache more than about 900 MB. Why?
> >>
> >> Caching never goes beyond ~900 MB (i.e. when I read a mounted drive with
> >> dd):
> >
> > Because blockdev mappings are limited to lowmem due to sharing their
> > cache with filesystem metadata cache, which needs kernel mapped memory.
> > It will >900MB of pagecache data OK (data from regular files)
>
> Does not help me, as what interests me here on these machines is mainly
> caching block device data; they are iSCSI targets and access block
> devices directly.

OK. Yeah, it's just due to crufty old code... I'm slowly working to
remove this limitation (can be done in 1 of 2 ways: either disconnect
filesystem metadata cache from blockdev data cache, or rework filesystems
to be able to handle highmem for metadata cache).

Actually the quickest way for you might be just to create a new type of
block device that can use highmem but not support filesystems.


> >> Same behaviour on 32 bit machines with 4 GB RAM.
> >>
> >> No problems on 64 bit machines.
> >> I have one 32 bit machine that caches beyond ~900 MB without problems.
> >
> > Does it have a different user/kernel split?
>
> Yes it does:
>
> CONFIG_VMSPLIT_2G_OPT=y
>
>
> What split should I choose to enable blockdev mapping on the whole
> memory on 32 bit system with 3 or 4 GB RAM? Is it possible with 4 GB RAM
> at all?

It's not possible to use 4GB RAM with VMSPLIT. You could use VMSPLIT_1G
to give the kernel the most amount of virtual memory. And even reduce
vmalloc space to get a few more MB with vmalloc= boot parameter.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2009-03-24 15:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-24  8:42 Tomasz Chmielewski
2009-03-24 15:20 ` Nick Piggin
2009-03-24 15:35   ` Tomasz Chmielewski
2009-03-24 15:42     ` Nick Piggin [this message]
2009-03-24 15:44     ` Christoph Lameter
2009-03-24 16:00       ` Tomasz Chmielewski
2009-03-24 16:24         ` Christoph Lameter

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=200903250242.35787.nickpiggin@yahoo.com.au \
    --to=nickpiggin@yahoo.com.au \
    --cc=linux-mm@kvack.org \
    --cc=mangoo@wpkg.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