mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
	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: Tue, 4 Oct 2016 22:34:36 -0800	[thread overview]
Message-ID: <20161005063435.mtw2keukyxwbwo2k@kmo-pixel> (raw)
In-Reply-To: <db64a8f3-cd15-2ccc-e120-ba0466f811d0@linux.vnet.ibm.com>

On Tue, Oct 04, 2016 at 07:55:12PM -0300, Mauricio Faria de Oliveira wrote:
> Hi Benjamin, Kent, and others,
> 
> Would you please comment / answer about this possible problem?
> Any feedback is appreciated.
> 
> Since commit e1bdd5f27a5b ("aio: percpu reqs_available") the maximum
> number of aio nr_events may be a function of num_possible_cpus() and
> actually be /inversely proportional/ to it (i.e., more CPUs lead to
> less system-wide aio nr_events). This is a problem on larger systems.
> 
> That's because if "nr_events < num_possible_cpus() * 4" (for example
> nr_events == 1) that counts as "num_possible_cpus() * 4" into aio_nr
> and against aio_max_nr
> 
>     static struct kioctx *ioctx_alloc(unsigned nr_events)
>     ...
>         nr_events = max(nr_events, num_possible_cpus() * 4);
>         nr_events *= 2;
>     ...
>         /* limit the number of system wide aios */
>     ....
>         if (aio_nr + nr_events > (aio_max_nr * 2UL) ||
>     ...
>             err = -EAGAIN;
>     ...
>         aio_nr += ctx->max_reqs;
>     ...
> 
> That problem is easily noticeable on a common POWER8 system:  160 CPUs
> (2 sockets * 10 cores/socket * 8 threads/core = 160 CPUs) limits the max
> AIO contexts with "io_setup(1, )" to 102 out of 64k (default ax_aio_nr):
> 
>     # cat /sys/devices/system/cpu/possible
>     0-159
> 
>     # cat /proc/sys/fs/aio-max-nr
>     65536
> 
>     # echo $(( 65536 / (160 * 4) ))
>     102
> 
> test-case snippet & output:
> 
>     for (i = 0; i < 65536; i++)
>         if (rc = io_setup(1, &ioctx[i]))
>             break;
> 
>     printf("rc = %d, i = %d\n", rc, i);
> 
>     > rc = -11, i = 102
> 
> (another problem is that the sysctl aio-nr grows larger than aio-max-nr,
> since it's checked against "aio_max_nr * 2")
> 
> So,
> 
> I've been trying to understand/fix this, but soon got stuck on options
> as I didn't quite get a few points.. if you could provide some insight,
> please, that would be really helpful:
> 
> - why "num_possible_cpus() * 4", and why "max(nr_events, <it>)" ?

For the scheme to work - percpu allocation of slots - we have to ensure that
there aren't too many unused slots stranded on other CPUs. The stranding is
limited to 1/4th of the slots as I figured any more than that could be too
unpredictable - the effective maximum number of in flight iocbs would vary too
much.

For systems with large numbers of CPUs, what I'd prefer to do is make it per
core or numa node or somesuch. But we don't have any infrastructure for that
equivilant to the alloc_percpu() stuff, so that's why I didn't do it at the
time.

  reply	other threads:[~2016-10-05  6:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-04 22:55 Mauricio Faria de Oliveira
2016-10-05  6:34 ` Kent Overstreet [this message]
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
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=20161005063435.mtw2keukyxwbwo2k@kmo-pixel \
    --to=kent.overstreet@gmail.com \
    --cc=bcrl@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®