On Mon, 30 Oct 2006 11:01:53 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> I thought a bit about the circular buffer implementation, and I would > share my ideas. Certainly. But please let's keep others in the loop by cc-in to the list (I took the liberty to add the cc). > "Linux device drivers" 3rd edition tells that accessing > vmalloc-allocated memory buffer is somewhat slower than accession > kmalloc or get_free_page buffers. Given the 128KB limit of kmalloc, I > suppose that the circular buffer should use a get_free_pages. Unfortunately this is not the limit against which we bump. Both kmalloc and get_free_pages are limited by the fragmentation. So we can't realistically expect to fetch more than 2 pages at a time through either of them. This is why I wrote on the blog that the buffer is contiguous in the virtual space. It's not going to be contiguous in the physical memory. The only question is, do we use vmalloc and use page tables to keep the map, or do we use kmalloc and keep the map ourselves. Traditionally, driver writers in Linux lean to vmalloc in such case, and I traditionally hated this trend because it makes life very hard for users of architectures with small vmalloc area (such as the old sparc of which I was the maintainer). So the usbmon's mmap seems like a perfect opportunity for me to demonstrate that Gerd was a lazy bum when he used vmalloc in V4L (^_^), or else demonstrate that I was wrong all along. > The circular buffer itself may use on big memory chunk or an array of > smaller buffer, one for each URB. The second way (somewhat similar to > packet socket mmap implementation) leads to possibly large memory > wasting and enforces an hard limit to the max amount of data for each > captured URB, but is slightly easier and perhaps less bug-prone. Thanks for reminding me. I'll look into socket mmap, but initially I discounted that because sockets fetch from the atomic pool. > The first way requires some method to retrieve the next offset into the > buffer. In your blog you suggest an ioctl operation. With another > approach, the 'next_urb' field could be added to the binary event > header. I dunno, I feel uneasy without a way to synchronize, or find the next header in the stream. So I considered the next_urb kind of trick, but rejected it. I thought that if the "fetch" ioctl returns not just one offset, but a list of offsets, it would provide basically the same speed as next_urb field. I have an exam of Wednesday, so I plan to look into this more later in the week. If you have something by the weekend, please share. I am looking forward to your agreement about the master API structure as I outlined (yes, without the next_urb field for now). -- Pete ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
