All of lore.kernel.org
 help / color / mirror / Atom feed
From: Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Miller <davem@davemloft.net>,
	johnpol@2ka.mipt.ru, netdev@vger.kernel.org, haoki@redhat.com,
	yoshfuji@linux-ipv6.org, yumiko.sugita.yf@hitachi.com,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Subject: Re: [RFC/PATCH 0/3] UDP memory usage accounting
Date: Mon, 01 Oct 2007 22:56:04 +0900	[thread overview]
Message-ID: <4700FC74.6000601@hitachi.com> (raw)
In-Reply-To: <20070929052008.GA1192@gondor.apana.org.au>

Herbert Xu wrote:
> On Fri, Sep 28, 2007 at 09:51:59PM -0700, David Miller wrote:
>> There is a per-socket send buffer limit, and there is a per-user open
>> file descriptor limit.  Multiply the two to determine how much system
>> memory the user can consume using sockets.
>
> We do have these limits but they're per-process, not per-user.
> Unless you lock down the number of processes each user can have
> to no more than a handful then this is basically useless.
>
> For example, let's say each socket can lock down 64K of kernel
> memory (which is quite easy to do BTW, just open a TCP/UDP socket,
> send data to it from another socket but keep the data in the
> socket by not calling recvmsg), and that each process can have
> 1024 file descriptors (the default), then each process can pin
>
> 64K x 1024 = 64M
>
> of memory.  So if the user can have 10 processes, then that's
> 640M of kernel memory that can be pinned down.  Usually the
> process limit is at least 10 times higher.

Thank you very mush for your comment.

What you pointed out is my motivation to make this patch.
I think that per-process limits won't help to solve this
problem.

  reply	other threads:[~2007-10-01 13:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-21 12:18 [RFC/PATCH 0/3] UDP memory usage accounting Satoshi OSHIMA
2007-09-21 12:58 ` Evgeniy Polyakov
2007-09-27 18:51   ` Hideo AOKI
2007-09-28 13:26   ` Satoshi OSHIMA
2007-09-29  3:21     ` Herbert Xu
2007-09-29  4:47       ` David Miller
2007-09-29  4:51         ` David Miller
2007-09-29  5:20           ` Herbert Xu
2007-10-01 13:56             ` Satoshi OSHIMA [this message]
2007-09-29  5:55         ` Herbert Xu
2007-10-01 13:57           ` Satoshi OSHIMA

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=4700FC74.6000601@hitachi.com \
    --to=satoshi.oshima.fk@hitachi.com \
    --cc=davem@davemloft.net \
    --cc=haoki@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=johnpol@2ka.mipt.ru \
    --cc=netdev@vger.kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=yumiko.sugita.yf@hitachi.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.