netdev.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).