Re: aio-core why not using SuS? [Re: [rfc] aio-core for 2.5.29 (Re: async-io API registration for 2.5.29)]

[Benjamin LaHaise]

On Fri, Aug 16, 2002 at 03:57:17AM +0200, Andrea Arcangeli wrote:
> you're saying you prefer glibc to wrap the aio_read/write/fsync and to
> redirect all them to lio_listio after converting the iocb from user API to
> kernel API, right? still I don't see why should we have different iocb,
> I would understsand if you say we should simply overwrite aio_lio_opcode
> inside the aio_read(3) inside glibc and to pass it over to kernel with a
> single syscalls if it's low cost to just set the lio_opcode, but having
> different data structures doesn't sounds the best still. I mean, it
> would be nicer if things would be more consistent.

The iocb is as minimally different from the posix aio api as possible.  The 
main reason for the difference is that struct sigevent is unreasonably huge.  
A lightweight posix aio implementation on top of the kernel API shares the 
fields between the kernel iocb and the posix aiocb.

> I don't see how the flushing flood is related to this, this is a normal
> syscall, any issue that applies to these aio_read/write/fsync should
> apply to all other syscalls too. Also the 4G starvation will be more
> likely fixed by x86-64 or in software by using a softpagesize larger
> than 4k so that the mem_map array doesn't load all the zone_normal.

A 4G/4G split flushes the TLB on every syscall.

		-ben
-- 
"You will be reincarnated as a toad; and you will be much happier."