Re: Status of AIO

[Dan Aloni <da-x@monatomic.org>]

On Mon, Mar 06, 2006 at 08:39:15PM -0500, Benjamin LaHaise wrote:
> On Mon, Mar 06, 2006 at 04:51:29PM -0800, David S. Miller wrote:
> > I think any such VM tricks need serious thought.  It has serious
> > consequences as far as cost especially on SMP.  Evgivny has some data
> > that shows this, and chapter 5 of Networking Algorithmics has a lot of
> > good analysis and paper references on this topic.
> 
> VM tricks do suck, so you just have to use the tricks that nobody else 
> is...  My thinking is to do something like the following: have a structure 
> to reference a set of pages.  When it is first created, it takes a reference 
> on the pages in question, and it is added to the vm_area_struct of the user 
> so that the vm can poke it for freeing when memory pressure occurs.  The 
> sk_buff dataref also has to have a pointer to the pageref added.  Now, the 
> trick to making it useful is as follows:
> 
> 	struct pageref {
> 		atomic_t	free_count;
> 		int		use_count;	/* protected by socket lock */
> 		...
> 		unsigned long	user_address;
> 		unsigned long	length;
> 		struct socket	*sock;		/* backref for VM */
> 		struct page	*pages[];
> 	};
[...]
> 
> It's probably easier to show this tx path with code that gets the details 
> right.

This somehow resembles the scatter-gatter lists already used in some 
subsystems such as the SCSI sg driver. 

BTW you have to make these pages Copy-On-Write before this procedure 
starts because you wouldn't want it to accidently fill the zero page, 
i.e. the VM will have to supply a unique set of pages otherwise it 
messes up.

-- 
Dan Aloni
da-x@monatomic.org, da-x@colinux.org, da-x@gmx.net, dan@xiv.co.il
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/