linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Matti Aarnio <matti.aarnio@zmailer.org>
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: Thu, 4 Aug 2005 17:19:38 +0200	[thread overview]
Message-ID: <20050804151938.GZ8266@wotan.suse.de> (raw)
In-Reply-To: <20050804142040.GB22165@mea-ext.zmailer.org>

On Thu, Aug 04, 2005 at 05:20:40PM +0300, Matti Aarnio wrote:
> SHM resources are non-swappable, thus I would not by default

Not true.

> let user programs go and allocate very much SHM spaces at all.
> Such is usually spelled as: "denial-of-service-attack"
> For that reason I would not raise builtin defaults either.

It is equivalent to allocating anymous memory in programs.

In theory you could limit it for each user by RLIMIT_NPROC*RLIMIT_AS,
but in practice that would be usually
If Linux ever gets a "max memory total used per user" rlimit it may make
sense to limit the shm growth caused by them to that, but that is not
there yet. In addition I want to point out that there are a zillion
of subsystems which can be used to allocate quite a lot of memory
(e.g. fill the socket buffers of a few hundred sockets)
So far nobody knows how to limit all of these and it's probably too hard
to do. The general wisdom is that if you want strong isolation like
that use a virtualized environment.

> > 
> > 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.
> 
> Err...  No thanks!   I would prefer to have even finer grained control
> of how much SHM somebody can allocate.  For normal user the value
> might be zero, but for users in a group "SHM1" there could be a level
> of N MB, etc.  (Except that such mechanisms are rather complex...)

shmmni will stay, although the defaults will be larger. If you really
want you can lower it, but in practice it won't buy you much if anything.

-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>

  parent reply	other threads:[~2005-08-04 15:19 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 [this message]
2005-08-04 22:49     ` Chen, Kenneth W
2005-08-04 22:54       ` Andi Kleen
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=20050804151938.GZ8266@wotan.suse.de \
    --to=ak@suse.de \
    --cc=anton@samba.org \
    --cc=cr@sap.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matti.aarnio@zmailer.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