All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benny Halevy <bhalevy@scylladb.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 17/20] aio: support for IO polling
Date: Wed, 28 Nov 2018 11:33:04 +0200	[thread overview]
Message-ID: <1b282e42a1573bbcba31bd628860b31ce9b60e5c.camel@scylladb.com> (raw)
In-Reply-To: <a58a7fd3-7994-0e30-40f7-f990a162205f@kernel.dk>

On Tue, 2018-11-27 at 08:24 -0700, Jens Axboe wrote:
> On 11/27/18 2:53 AM, Benny Halevy wrote:
> > > @@ -818,11 +853,15 @@ static int kill_ioctx(struct mm_struct *mm, struct kioctx *ctx,
> > >  {
> > >  	struct kioctx_table *table;
> > >  
> > > +	mutex_lock(&ctx->getevents_lock);
> > >  	spin_lock(&mm->ioctx_lock);
> > >  	if (atomic_xchg(&ctx->dead, 1)) {
> > >  		spin_unlock(&mm->ioctx_lock);
> > > +		mutex_unlock(&ctx->getevents_lock);
> > >  		return -EINVAL;
> > >  	}
> > > +	aio_iopoll_reap_events(ctx);
> > > +	mutex_unlock(&ctx->getevents_lock);
> > 
> > Is it worth handling the mutex lock and calling aio_iopoll_reap_events
> > only if (ctx->flags & IOCTX_FLAG_IOPOLL)?  If so, testing it can be
> > removed from aio_iopoll_reap_events() (and maybe it could even
> > be open coded
> > here since this is its only call site apparently)
> 
> I don't think it really matters, this only happens when you tear down an
> io_context. FWIW, I think it's cleaner to retain the test in the
> function, not outside it.
> 
> > > @@ -1072,6 +1112,15 @@ static inline void iocb_put(struct aio_kiocb *iocb)
> > >  	}
> > >  }
> > >  
> > > +static void iocb_put_many(struct kioctx *ctx, void **iocbs, int *nr)
> > > +{
> > > +	if (nr) {
> > 
> > How can nr by NULL?
> > And what's the point of supporting this case?
> > Did you mean: if (*nr)?
> > (In this case, if safe to call the functions below with *nr==0,
> > I'm not sure it's worth optimizing... especially since this is a static
> > function and its callers make sure to call it only when *nr > 0)
> 
> Indeed, that should be if (*nr), thanks! The slub implementation of the
> bulk free complains if you pass in nr == 0. Outside of that, a single
> check should be better than checking in multiple spots.
> 

Cool. The compiler might also optimize it away when inlining this function
if the caller tests *nr for being non-zero too.

> > > @@ -1261,6 +1310,166 @@ static bool aio_read_events(struct kioctx *ctx, long min_nr, long nr,
> > >  	return ret < 0 || *i >= min_nr;
> > >  }
> > >  
> > > +#define AIO_IOPOLL_BATCH	8
> > > +
> > > +/*
> > > + * Process completed iocb iopoll entries, copying the result to userspace.
> > > + */
> > > +static long aio_iopoll_reap(struct kioctx *ctx, struct io_event __user *evs,
> > > +			    unsigned int *nr_events, long max)
> > > +{
> > > +	void *iocbs[AIO_IOPOLL_BATCH];
> > > +	struct aio_kiocb *iocb, *n;
> > > +	int to_free = 0, ret = 0;
> > > +
> > > +	list_for_each_entry_safe(iocb, n, &ctx->poll_completing, ki_list) {
> > > +		if (*nr_events == max)
> > 
> > *nr_events >= max would be safer.
> 
> I don't see how we can get there with it being larger than already, that
> would be a big bug if we fill more events than userspace asked for.
> 

Currently we indeed can't, but if the code changes in the future
and we do, this will reduce the damage - hence being safer (and it costs nothing
in terms of performance).

> > > @@ -1570,17 +1829,43 @@ static inline void aio_rw_done(struct kiocb *req, ssize_t ret)
> > >  	default:
> > >  		req->ki_complete(req, ret, 0);
> > >  	}
> > > +
> > 
> > nit: this hunk is probably unintentional
> 
> Looks like it, I'll kill it.
> 
> 


  reply	other threads:[~2018-11-28  9:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-26 16:45 [PATCHSET v3 0/18] Support for polled aio Jens Axboe
2018-11-26 16:45 ` [PATCH 01/20] aio: fix failure to put the file pointer Jens Axboe
2018-11-27  8:16   ` Johannes Thumshirn
2018-11-26 16:45 ` [PATCH 02/20] aio: clear IOCB_HIPRI Jens Axboe
2018-11-27  8:18   ` Johannes Thumshirn
2018-11-26 16:45 ` [PATCH 03/20] fs: add an iopoll method to struct file_operations Jens Axboe
2018-11-27  8:24   ` Johannes Thumshirn
2018-11-26 16:45 ` [PATCH 04/20] block: wire up block device iopoll method Jens Axboe
2018-11-27  8:29   ` Johannes Thumshirn
2018-11-26 16:45 ` [PATCH 05/20] block: ensure that async polled IO is marked REQ_NOWAIT Jens Axboe
2018-11-26 16:45 ` [PATCH 06/20] iomap: wire up the iopoll method Jens Axboe
2018-11-26 16:45 ` [PATCH 07/20] iomap: ensure that async polled IO is marked REQ_NOWAIT Jens Axboe
2018-11-26 16:45 ` [PATCH 08/20] aio: use assigned completion handler Jens Axboe
2018-11-26 16:45 ` [PATCH 09/20] aio: separate out ring reservation from req allocation Jens Axboe
2018-11-26 16:45 ` [PATCH 10/20] aio: don't zero entire aio_kiocb aio_get_req() Jens Axboe
2018-11-26 16:45 ` [PATCH 11/20] aio: only use blk plugs for > 2 depth submissions Jens Axboe
2018-11-26 16:45 ` [PATCH 12/20] aio: use iocb_put() instead of open coding it Jens Axboe
2018-11-26 16:45 ` [PATCH 13/20] aio: split out iocb copy from io_submit_one() Jens Axboe
2018-11-26 16:45 ` [PATCH 14/20] aio: abstract out io_event filler helper Jens Axboe
2018-11-26 16:45 ` [PATCH 15/20] aio: add io_setup2() system call Jens Axboe
2018-11-26 16:45 ` [PATCH 16/20] aio: add support for having user mapped iocbs Jens Axboe
2018-11-26 16:45 ` [PATCH 17/20] aio: support for IO polling Jens Axboe
2018-11-27  9:53   ` Benny Halevy
2018-11-27 15:24     ` Jens Axboe
2018-11-28  9:33       ` Benny Halevy [this message]
2018-11-28 18:50         ` Jens Axboe
2018-11-29 14:10           ` Benny Halevy
2018-11-26 16:45 ` [PATCH 18/20] aio: add submission side request cache Jens Axboe
2018-11-26 16:45 ` [PATCH 19/20] fs: add fget_many() and fput_many() Jens Axboe
2018-11-26 16:45 ` [PATCH 20/20] aio: use fget/fput_many() for file references Jens Axboe

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=1b282e42a1573bbcba31bd628860b31ce9b60e5c.camel@scylladb.com \
    --to=bhalevy@scylladb.com \
    --cc=axboe@kernel.dk \
    --cc=linux-aio@kvack.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /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.