Messages in this thread | | | Date | Tue, 7 Mar 2006 04:04:11 +0200 | From | Dan Aloni <> | Subject | Re: Status of AIO |
| |
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/
| |