On Mon, Aug 3, 2020 at 4:56 PM Jens Axboe wrote:
>
> What I ended up with after the last email was just removing the test
> bit:
>
> https://git.kernel.dk/cgit/linux-block/commit/?h=io_uring-5.9&id=cbd287c09351f1d3a4b3cb9167a2616a11390d32
>
> and I clarified the comments on the io_async_buf_func()
On 8/3/20 5:49 PM, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 4:31 PM Jens Axboe wrote:
>>
>> Updated to honor exclusive return value as well:
>
> See my previous email, You're just adding code that makes no sense,
> because your wait entry fundamentally isn't an exclusive one.
Right, I get
On Mon, Aug 3, 2020 at 4:31 PM Jens Axboe wrote:
>
> Updated to honor exclusive return value as well:
See my previous email, You're just adding code that makes no sense,
because your wait entry fundamentally isn't an exclusive one.
So all that code is a no-op and only makes it more confusing to
On 8/3/20 5:34 PM, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 4:18 PM Jens Axboe wrote:
>>
>>
>> I took a look at the rewrite you queued up, and made a matching change
>> on the io_uring side:
>
> Oh, no, you made it worse.
>
> Now you're tying your odd wakeup routine to entirely irrelevant
On Mon, Aug 3, 2020 at 4:18 PM Jens Axboe wrote:
>
>
> I took a look at the rewrite you queued up, and made a matching change
> on the io_uring side:
Oh, no, you made it worse.
Now you're tying your odd wakeup routine to entirely irrelevant things
that can't even happen to you.
That io_async_bu
On 8/3/20 5:18 PM, Jens Axboe wrote:
> On 8/3/20 4:30 PM, Jens Axboe wrote:
>>> Adding random kiocb helper functions to a core header file, when they
>>> are only used in one place, and when they only make sense in that one
>>> place?
>>>
>>> Not ok.
>>
>> I'll move that into io_uring instead.
>
>
On 8/3/20 4:30 PM, Jens Axboe wrote:
>> Adding random kiocb helper functions to a core header file, when they
>> are only used in one place, and when they only make sense in that one
>> place?
>>
>> Not ok.
>
> I'll move that into io_uring instead.
I see that you handled most of the complaints al
On 8/3/20 3:10 PM, Konstantin Ryabitsev wrote:
> On Mon, Aug 03, 2020 at 01:53:12PM -0700, Linus Torvalds wrote:
>> On Mon, Aug 3, 2020 at 1:48 PM Linus Torvalds
>> wrote:
>>>
>>> I've pushed out my merge of this thing [..]
>>
>> It seems I'm not the only one unhappy with the pull request.
>>
>> F
On 8/3/20 2:48 PM, Linus Torvalds wrote:
> On Sun, Aug 2, 2020 at 2:41 PM Jens Axboe wrote:
>>
>> Lots of cleanups in here, hardening the code and/or making it easier to
>> read and fixing buts, but a core feature/change too adding support for
>> real async buffered reads. With the latter in place
On Mon, Aug 03, 2020 at 01:53:12PM -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2020 at 1:48 PM Linus Torvalds
> wrote:
> >
> > I've pushed out my merge of this thing [..]
>
> It seems I'm not the only one unhappy with the pull request.
>
> For some reason I also don't see pr-tracker-bot being
On Mon, Aug 3, 2020 at 1:48 PM Linus Torvalds
wrote:
>
> I've pushed out my merge of this thing [..]
It seems I'm not the only one unhappy with the pull request.
For some reason I also don't see pr-tracker-bot being all happy and
excited about it. I wonder why.
Linus
On Sun, Aug 2, 2020 at 2:41 PM Jens Axboe wrote:
>
> Lots of cleanups in here, hardening the code and/or making it easier to
> read and fixing buts, but a core feature/change too adding support for
> real async buffered reads. With the latter in place, we just need
> buffered write async support a
Hi Linus,
Lots of cleanups in here, hardening the code and/or making it easier to
read and fixing buts, but a core feature/change too adding support for
real async buffered reads. With the latter in place, we just need
buffered write async support and we're done relying on kthreads for the
fast pa
13 matches
Mail list logo
