Re: [PATCH 0 of 4] Generic AIO by scheduling stacks

[Zach Brown]

> The only thing I saw in Zach's post against the use of threads is that
> some kernel API would change. But surely if this is the showstopper  
> then
> there must be some better argument than sys_getpid()?!

Haha, yeah, that's the silly example I keep throwing around :).  I  
guess it does leave a little too much of the exercise up to the reader.

Perhaps a less goofy example are the uses of current->ioprio and  
current->io_context?

If you create and destroy threads around each operation then you're  
going to be creating and destroying an io_context around each op  
instead of getting a reference on a pre-existing context in  
additional ops.  ioprio is inherited it seems, though, so that's not  
so bad.

If you have a pool of threads and you want to update the ioprio for  
future IOs, you now have to sync up the pool's ioprio with new  
desired priority.

It's all solvable, sure.  Get an io_context ref in copy_process().   
Share ioprio instead of inheriting it.  Have a fun conversation with  
Jens about the change in behaviour this implies.  Broadcasting to  
threads to update ioprio isn't exactly rocket science.

But with the fibril model the user don't have to know to worry about  
the inconsistencies and we kernel developers don't have to worry  
about pro-actively stamping them out.  A series of sync write and  
ioprio setting calls behaves exactly the same as that series of calls  
issued sequentially as "async" calls.  That's worth aiming for, I think.

- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/