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."
next prev parent 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.