Am 23.03.2026 um 18:04 hat Hanna Czenczek geschrieben: > On 23.03.26 18:02, Hanna Czenczek wrote: > > On 23.03.26 17:36, Kevin Wolf wrote: > > > Am 18.03.2026 um 16:32 hat Hanna Czenczek geschrieben: > > > > Put all request parameters into the qemu_laiocb struct, which > > > > will allow > > > > re-submitting the tail of short reads/writes. > > > > > > > > Signed-off-by: Hanna Czenczek <[email protected]> > > > > --- > > > > block/linux-aio.c | 35 ++++++++++++++++++++++------------- > > > > 1 file changed, 22 insertions(+), 13 deletions(-) > > > > > > > > diff --git a/block/linux-aio.c b/block/linux-aio.c > > > > index 53c3e9af8a..1f25339dc9 100644 > > > > --- a/block/linux-aio.c > > > > +++ b/block/linux-aio.c > > > > @@ -40,10 +40,15 @@ struct qemu_laiocb { > > > > Coroutine *co; > > > > LinuxAioState *ctx; > > > > struct iocb iocb; > > > > + int fd; > > > > ssize_t ret; > > > > + off_t offset; > > > > size_t nbytes; > > > > QEMUIOVector *qiov; > > > > - bool is_read; > > > > + > > > > + int type; > > > If you put fd and type next to each other, you'd avoid a hole in the > > > struct. > > > > And I assume pulling dev_max_batch forward, after qiov, yes. > > Noticed while sending: I missed `.next` for some reason. So no reason to > pull dev_max_batch forward, and I guess there will always be a hole, but I > suppose it is still best to put all 32-bit ints next to each other (fd, > type, flags) so filling that up in the future is more likely.
Ah, yes, I missed that flags is only 32 bits, too. I'm sure that things could still be rearranged to be more optimal, and I'm also sure it's premature optimisation. Sorry for the noise. Kevin
