public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <kmo@daterainc.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Sedat Dilek <sedat.dilek@gmail.com>,
	Dave Jones <davej@codemonkey.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>, Chris Mason <clm@fb.com>
Subject: Re: Linux 3.19-rc3
Date: Tue, 6 Jan 2015 04:18:06 -0800	[thread overview]
Message-ID: <20150106121806.GC26845@kmo-pixel> (raw)
In-Reply-To: <20150106115822.GU29390@twins.programming.kicks-ass.net>

On Tue, Jan 06, 2015 at 12:58:22PM +0100, Peter Zijlstra wrote:
> On Tue, Jan 06, 2015 at 03:07:30AM -0800, Kent Overstreet wrote:
> > http://evilpiepirate.org/git/linux-bcache.git/log/?h=aio_ring_fix
> 
> Very terse changelogs there :/

erg, I've been slacking on changelogs lately. that closure_sync() fix definitely
merits explanation.

> Also, I'm not sure I agree with that whole closure_wait_event*() stuff,
> the closure interface as it exist before that makes sense, but now
> you're just mixing up things.
> 
> Why would you want to retrofit a lot of the wait_event*() stuff on top
> of this?

Actually it's not retrofitted, closure_wait_event() dates to the very original
closure code, it was dropped for awhile because bcache happened not to be using
it anymore and I just dug it out of the git history.

Think of it this way - closures wait on things: sometimes you want to wait
asynchronously, sometimes synchronously, but you want the same primitives for
both - something has to bridge the gap between the async and sync stuff.

For example - here's the code in the bcache-dev branch that handles reading the
journal from each device in the cache set in parallel:

http://evilpiepirate.org/git/linux-bcache.git/tree/drivers/md/bcache/journal.c?h=bcache-dev#n399

It's using closure_call() to kick off the read for each device, then
closure_sync() to wait on them all to finish.

So closure_sync() is completely necessary, and then once you've got that
closure_wait_event() is just a trivial macro.

Also, closures could be using wait_queue_head_t instead of closure waitlist,
mainly I didn't want to nearly double the size of closures to stuff in a
__wait_queue.

I'd argue that "closures the junk for writing weird pseudo continuation passing
style asynchronous C" are not really the important parts of closures, the
important part is the infrastructure for waiting on stuff and then doing
something when that stuff completes. closure_get(), closure_put() and waitlists
are the real primitives; both closure_sync() and all the fancy asynchronous
stuff are built on top of that.

  reply	other threads:[~2015-01-06 12:15 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06  4:49 Linux 3.19-rc3 Sedat Dilek
2015-01-06  9:34 ` Sedat Dilek
2015-01-06  9:56   ` Takashi Iwai
2015-01-06 10:06     ` Sedat Dilek
2015-01-06 10:28       ` Takashi Iwai
2015-01-06 10:31         ` Sedat Dilek
2015-01-06 10:37           ` Takashi Iwai
2015-01-06 10:42             ` Sedat Dilek
2015-01-06  9:59   ` Peter Zijlstra
2015-01-06  9:40 ` Peter Zijlstra
2015-01-06  9:42   ` Sedat Dilek
2015-01-06  9:57     ` Sedat Dilek
2015-01-06 10:06       ` Peter Zijlstra
2015-01-06 10:18         ` Sedat Dilek
2015-01-06 11:01           ` Peter Zijlstra
2015-01-06 11:07             ` Kent Overstreet
2015-01-06 11:25               ` Sedat Dilek
2015-01-06 11:40                 ` Kent Overstreet
2015-01-06 12:51                   ` Sedat Dilek
2015-01-06 11:42               ` Peter Zijlstra
2015-01-06 11:48                 ` Peter Zijlstra
2015-01-06 12:01                   ` Kent Overstreet
2015-01-06 12:20                     ` Peter Zijlstra
2015-01-06 12:45                       ` Kent Overstreet
2015-01-06 12:55                       ` Peter Hurley
2015-01-06 17:38                         ` Paul E. McKenney
2015-01-06 17:58                           ` Peter Hurley
2015-01-06 19:25                             ` Paul E. McKenney
2015-01-06 19:57                               ` Peter Hurley
2015-01-06 20:47                                 ` Paul E. McKenney
2015-01-20  0:30                                   ` Paul E. McKenney
2015-01-20 14:03                                     ` Peter Hurley
2015-02-02 16:11                                       ` Paul E. McKenney
2015-02-02 19:03                                         ` Peter Hurley
2015-02-02 19:33                                           ` Paul E. McKenney
2015-01-06 11:56                 ` Kent Overstreet
2015-01-06 12:16                   ` Peter Zijlstra
2015-01-06 12:43                     ` Kent Overstreet
2015-01-06 13:03                       ` Peter Zijlstra
2015-01-06 13:28                         ` Kent Overstreet
2015-01-13 15:23                           ` Peter Zijlstra
2015-01-06 11:58               ` Peter Zijlstra
2015-01-06 12:18                 ` Kent Overstreet [this message]
2015-01-16 16:56               ` Peter Hurley
2015-01-16 17:00                 ` Chris Mason
2015-01-16 18:58                   ` Peter Hurley
2015-01-06 10:29   ` Sedat Dilek
  -- strict thread matches above, loose matches on Subject: below --
2015-01-06  1:46 Linus Torvalds
2015-01-06  2:46 ` Dave Jones
2015-01-06  8:18   ` Takashi Iwai
2015-01-06  9:45   ` Jiri Kosina
2015-01-08 12:51 ` Mark Langsdorf
2015-01-08 13:45   ` Catalin Marinas
2015-01-08 17:29     ` Mark Langsdorf
2015-01-08 17:34       ` Catalin Marinas
2015-01-08 18:48         ` Mark Langsdorf
2015-01-08 19:21           ` Linus Torvalds
2015-01-09 23:27             ` Catalin Marinas
2015-01-10  0:35               ` Kirill A. Shutemov
2015-01-10  2:27                 ` Linus Torvalds
2015-01-10  2:51                   ` David Lang
2015-01-10  3:06                     ` Linus Torvalds
2015-01-10 10:46                       ` Andreas Mohr
2015-01-10 19:42                         ` Linus Torvalds
2015-01-13  3:33                     ` Rik van Riel
2015-01-13 10:28                       ` Catalin Marinas
2015-01-10  3:17                   ` Tony Luck
2015-01-10 20:16                   ` Arnd Bergmann
2015-01-10 21:00                     ` Linus Torvalds
2015-01-10 21:36                       ` Arnd Bergmann
2015-01-10 21:48                         ` Linus Torvalds
2015-01-12 11:37                         ` Kirill A. Shutemov
2015-01-12 12:18                         ` Catalin Marinas
2015-01-12 13:57                           ` Arnd Bergmann
2015-01-12 14:23                             ` Catalin Marinas
2015-01-12 15:42                               ` Arnd Bergmann
2015-01-12 11:53                     ` Catalin Marinas
2015-01-12 13:15                       ` Arnd Bergmann
2015-01-08 15:08   ` Michal Hocko
2015-01-08 16:37     ` Mark Langsdorf
2015-01-09 15:56       ` Michal Hocko
2015-01-09 12:13   ` Mark Rutland
2015-01-09 14:19     ` Steve Capper
2015-01-09 14:27       ` Mark Langsdorf
2015-01-09 17:57         ` Mark Rutland
2015-01-09 18:37           ` Marc Zyngier
2015-01-09 19:43             ` Will Deacon
2015-01-10  3:29               ` Laszlo Ersek
2015-01-10  4:39                 ` Linus Torvalds
2015-01-10 13:37                   ` Will Deacon
2015-01-10 19:47                     ` Laszlo Ersek
2015-01-10 19:56                       ` Linus Torvalds
2015-01-10 20:08                         ` Laszlo Ersek
2015-01-10 19:51                     ` Linus Torvalds
2015-01-12 12:42                       ` Will Deacon
2015-01-12 13:22                         ` Mark Langsdorf
2015-01-12 19:03                         ` Dave Hansen
2015-01-12 19:06                         ` Linus Torvalds
2015-01-12 19:07                           ` Linus Torvalds
2015-01-12 19:24                             ` Will Deacon
2015-01-10 15:22                 ` Kyle McMartin

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=20150106121806.GC26845@kmo-pixel \
    --to=kmo@daterainc.com \
    --cc=clm@fb.com \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=sedat.dilek@gmail.com \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox