Re: changes to kiobuf support in 2.4.(?)4

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Aug 02, 2001 at 01:42:21AM -0700, Jeremy Higdon wrote:
> My understanding is that databases like to have multiple outstanding
> requests to the same file, which I believe falls into the the multiple
> file descriptors, one file case.  So for us, it is interesting.  Or
> do I misunderstand what you wrote?

the databases I know open the file without sharing the fd, so they're
fine even if we share the same iobuf from multiple fd. Infact even with
threads you can open the same file multiple times.

> Actually, I want to be clear on this . . .
> 
> 	If I do
> 
> 	dd if=/dev/raw1 . . . &
> 	dd if=/dev/raw1 . . . &
> 	wait
> 
> with the O_DIRECT patch, do I get some slow path allocations?

That will work fine with the per-file iobuf ala O_DIRECT, no slow path
allocations will ever happen.

Even if you do:

	clone()
	parent:
		fd = open("/dev/raw1")
		write(fd)
		read(fd)
	child:
		fd = open("/dev/raw1")
		write(fd)
		read(fd)

you won't run into slow path allocations.

> At 13000 IOPS, when allocating and freeing on every I/O request,
> the allocate/free overhead was approximately .6% on a 2 CPU system,
> where the total overhead was about 25%.  So I would theoretically
> gain 3% (maybe a little better since there is locking involved) if
> I could avoid the alloc/free.

Ok good.

Andrea