On Fri, Jul 10, 2020 at 6:59 PM Kanchan Joshi [off-list ref] wrote:

On Fri, Jul 10, 2020 at 6:39 PM Christoph Hellwig [off-list ref] wrote:

quoted

On Thu, Jul 09, 2020 at 12:50:27PM -0600, Jens Axboe wrote:

quoted

It might, if you have IRQ context for the completion. task_work isn't
expensive, however. It's not like a thread offload.

Not sure about polled-completion but we have IRQ context for regular completion.
If I've got it right, I need to store task_struct during submission,
and use that to register a task_work during completion. At some point
when this task_work gets called it will update the user-space pointer
with the result.
It can be the case that we get N completions parallely, but they all
would get serialized because all N task-works need to be executed in
the context of single task/process?

quoted

quoted

quoted

Using flags have not been liked here, but given the upheaval involved so
far I have begun to feel - it was keeping things simple. Should it be
reconsidered?

It's definitely worth considering, especially since we can use cflags
like Pavel suggested upfront and not need any extra storage. But it
brings us back to the 32-bit vs 64-bit discussion, and then using blocks
instead of bytes. Which isn't exactly super pretty.

block doesn't work for the case of writes to files that don't have
to be aligned in any way.  And that I think is the more broadly
applicable use case than zone append on block devices.

But when can it happen that we do zone-append on a file (zonefs I
asssume), and device returns a location (write-pointer essentially)
which is not in multiple of 512b?


--
Joshi

-- 
Joshi