site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Hello List, Yuck. You should. Have you tried it? = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... devmaillists wrote: I need some additional information to genIO64VMSegments. Google does not really find something about this. We are writing a driver for a PCI Card and DMA Data should be transferred in multiples of 4K ( page size ). This is because of the memory layout on the card and to let the card take a breath between the transfers. If if I set initWithSpecification maxSegmentSize to 4K ( I expect this to be the native page size), do I get only 4K "physically continous segments" with IOVMSegments. Sure the last one will be short. Is there a way to tell the IOMemoryDescriptor to generate physically continous segments with a defined size?. The IOMemoryDescriptor doesn't "generate segments"; it simply allows you to temporarily freeze the current layout of a particular region of memory. The VM system is responsible for the allocation of physical pages, and it does not as a general rule make any attempt to organise pages contiguously. Is there a general rule how large a MemDesc can be to get prepared without igniting a lot of paging? It depends entirely on the working set size for the system at the time you prepare the IOMemoryDescriptor (I assume that's what you mean by 'MemDesc'). As a general rule, since you can't know what the system is doing, you should try to balance the time your device takes to do work on the descriptor vs. the overhead involved in setting it up and tearing it down. A ratio of 2:1 between work time and setup/teardown time is a good lower limit; beyond 10:1 is often not worth pursuing due to diminishing returns. This email sent to site_archiver@lists.apple.com