All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Cc: Kent Overstreet <kent.overstreet@gmail.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: aio: questions with ioctx_alloc() and large num_possible_cpus()
Date: Wed, 5 Oct 2016 14:17:41 -0400	[thread overview]
Message-ID: <20161005181741.GL23336@kvack.org> (raw)
In-Reply-To: <737b5bf7-329e-c59d-7601-aea0f4ffbeab@linux.vnet.ibm.com>

On Wed, Oct 05, 2016 at 02:58:12PM -0300, Mauricio Faria de Oliveira wrote:
> Hi Benjamin,
> 
> On 10/05/2016 02:41 PM, Benjamin LaHaise wrote:
> >I'd suggest increasing the default limit by changing how it is calculated.
> >The current number came about 13 years ago when machines had orders of
> >magnitude less RAM than they do today.
> 
> Thanks for the suggestion.
> 
> Does the default also have implications other than memory usage?
> For example, concurrency/performance of as much aio contexts running,
> or if userspace could try to exploit some point with a larger number?

Anything's possible when a local user can run code.  It's the same problem 
as determining how much memory can be mlock()ed, or how much i/o a process 
should be allowed to do.  Nothing prevents an app from doing a huge amount 
of readahed() calls to make the system prefetch gigabytes of data.  That 
said, local users tend not to DoS themselves.

> Wondering about it because it can be set based on num_possible_cpus(),
> but that might be really large on high-end systems.

Today's high end systems are tomorrow's desktops...  It probably makes 
sense to implement per-user limits rather than the current global limit, 
and maybe even convert them to an rlimit to better fit in with the 
available frameworks for managing these things.

		-ben

> Regards,
> 
> -- 
> Mauricio Faria de Oliveira
> IBM Linux Technology Center

-- 
"Thought is the essence of where you are now."

  reply	other threads:[~2016-10-05 18:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 22:55 aio: questions with ioctx_alloc() and large num_possible_cpus() Mauricio Faria de Oliveira
2016-10-05  6:34 ` Kent Overstreet
2016-10-05 17:21   ` Mauricio Faria de Oliveira
2016-10-05 17:41 ` Benjamin LaHaise
2016-10-05 17:58   ` Mauricio Faria de Oliveira
2016-10-05 18:17     ` Benjamin LaHaise [this message]
2016-10-05 19:22       ` Mauricio Faria de Oliveira
2016-10-28 18:59       ` Jeff Moyer

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=20161005181741.GL23336@kvack.org \
    --to=bcrl@kvack.org \
    --cc=kent.overstreet@gmail.com \
    --cc=linux-aio@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mauricfo@linux.vnet.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.