All of lore.kernel.org
 help / color / mirror / Atom feed
From: "krautus@kr916.org" <krautus@kr916.org>
To: xfs@oss.sgi.com
Cc: Johannes Truschnigg <johannes.truschnigg@geizhals.at>
Subject: Re: all your slabs are belong to ram ?
Date: Tue, 6 Oct 2015 20:34:49 +0200	[thread overview]
Message-ID: <20151006203449.065d26f3@linux> (raw)
In-Reply-To: <eb3a907a5224885d97b47c86a9293545.squirrel@mail.geizhals.at>

Thank you very much, will do!
(and report back the results)

Regards and thanks for supporting,
Mike


On Tue, 6 Oct 2015 18:16:46 +0200
"Johannes Truschnigg" <johannes.truschnigg@geizhals.at> wrote:

> Am Di, 6.10.2015, 16:50 schrieb Darrick J. Wong:
> > On Tue, Oct 06, 2015 at 04:24:43PM +0200, krautus@kr916.org wrote:
> >> [...]
> >> So I'm asking you:
> >> 1. is there a way to force dentries and inodes to stay in ram ?
> >> 2. can I perhaps move dentries and inodes to a dedicated SSD ?
> >>
> >> I'm open to all possibilities, perhaps increase RAM ?
> >> Upgrade to Debian Jessie and 64 bit ?
> >
> > ISTR that kernel data such as slabs cannot live in highmem, which means
> > that
> > dentries and slab cannot live in highmem.  A 32bit kernel sets up ~900M of
> > low
> > memory and ~15G of highmem, which is probably why the kernel has to evict
> > things and why you see such problems.
> >
> > A 64bit kernel sets up all the memory as lowmem, so the kernel can use all
> > the
> > memory for stuff like that.  I'd give that a try first.
> 
> A few years back, we solved pretty much that exact same problem by
> switching the kernel to amd64, with all of userspace remaining i386. You
> should definitely try this.
> 
> -- 
> Mit freundlichen Grüßen
> Johannes Truschnigg
> Senior System Administrator
> --
> mailto:johannes.truschnigg@geizhals.at (in dringenden Fällen bitte an
> info@geizhals.at)
> 
> Geizhals(R) - Preisvergleich Internet Services AG
> Obere Donaustrasse 63/2
> A-1020 Wien
> Tel: +43 1 5811609/87
> Fax: +43 1 5811609/55
> http://geizhals.at => Preisvergleich für Österreich
> http://geizhals.de => Preisvergleich für Deutschland
> http://geizhals.eu => Preisvergleich EU-weit
> Handelsgericht Wien | FN 197241K | Firmensitz Wien
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      reply	other threads:[~2015-10-06 18:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06 14:24 all your slabs are belong to ram ? krautus
2015-10-06 14:50 ` Darrick J. Wong
2015-10-06 16:16   ` Johannes Truschnigg
2015-10-06 18:34     ` krautus [this message]

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=20151006203449.065d26f3@linux \
    --to=krautus@kr916.org \
    --cc=johannes.truschnigg@geizhals.at \
    --cc=xfs@oss.sgi.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.