linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: 'Andi Kleen' <ak@suse.de>, Hugh Dickins <hugh@veritas.com>,
	linux-kernel@vger.kernel.org, Anton Blanchard <anton@samba.org>,
	cr@sap.com, linux-mm@kvack.org
Subject: Re: Getting rid of SHMMAX/SHMALL ?
Date: Fri, 5 Aug 2005 00:54:13 +0200	[thread overview]
Message-ID: <20050804225413.GH8266@wotan.suse.de> (raw)
In-Reply-To: <200508042249.j74Mndg18582@unix-os.sc.intel.com>

On Thu, Aug 04, 2005 at 03:49:37PM -0700, Chen, Kenneth W wrote:
> Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM
> > I think we should just get rid of the per process limit and keep
> > the global limit, but make it auto tuning based on available memory.
> > That is still not very nice because that would likely keep it < available 
> > memory/2, but I suspect databases usually want more than that. So
> > I would even make it bigger than tmpfs for reasonably big machines.
> > Let's say
> > 
> > if (main memory >= 1GB)
> > 	maxmem = main memory - main memory/8 
> 
> This might be too low on large system.  We usually stress shm pretty hard
> for db application and usually use more than 87% of total memory in just
> one shm segment.  So I prefer either no limit or a tunable.

With large system you mean >32GB right?

I think on a large systems some tuning is reasonable because they likely
have trained admins. I'm more worried on reasonable defaults for the
class of systems with 0-4GB

The /8 was to account for the overhead of page tables and mem_map and
leave some other memory for the system, but you're right it might be less 
with hugetlbfs.

-Andi
--
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:[~2005-08-04 22:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-04 11:39 Andi Kleen
2005-08-04 11:58 ` linux-os (Dick Johnson)
2005-08-04 13:19 ` Hugh Dickins
2005-08-04 13:23   ` Andi Kleen
2005-08-04 14:20     ` Matti Aarnio
2005-08-04 14:48       ` Hugh Dickins
2005-08-07 11:38         ` Alan Cox
2005-08-04 15:19       ` Andi Kleen
2005-08-04 22:49     ` Chen, Kenneth W
2005-08-04 22:54       ` Andi Kleen [this message]
2005-08-04 22:58         ` Chen, Kenneth W
2005-08-04 13:34   ` Jakob Oestergaard

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=20050804225413.GH8266@wotan.suse.de \
    --to=ak@suse.de \
    --cc=anton@samba.org \
    --cc=cr@sap.com \
    --cc=hugh@veritas.com \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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