On Fri, Jul 10, 2020 at 6:59 PM Kanchan Joshi <joshiiitr@xxxxxxxxx> wrote: > > On Fri, Jul 10, 2020 at 6:39 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > On Thu, Jul 09, 2020 at 12:50:27PM -0600, Jens Axboe wrote: > > > 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? > > > > 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
