Hi, I'm writing a driver for a sampling device that is constantly delivering a relatively high amount of data (about 16 MB/s) and I need to deliver the data to the user-space ASAP. To prevent data loss I create a queue of buffers (consisting of few pages each) which are more or less directly filled by the device and then mapped to the user-space via mmap().
The thing is that I'd like to prevent kernel to swap these pages out, because then I may loose some data when they are not available in time for the next round. My original idea (that used to work in the past) was to allocate the buffers using __get_free_pages(), then pin the pages down by setting their PG_reserved bit in the page flags before using them. And then set the VM_RESERVED flag of the appropriate VMA when mmap() is called for these pages that are then mapped using nopage() mechanism. But this way no longer seems to work correctly, it kind of works, but I'm getting following messages for each mmapped page upon munmap() call: -------------------------------------- [19172.939248] Bad page state in process 'dtrtest' [19172.939249] page:ffff81000160a978 flags:0x001a000000000404 mapping:0000000000000000 mapcount:0 count:0 [19172.939251] Trying to fix it up, but a reboot is needed [19172.939253] Backtrace: [19172.939256] [19172.939257] Call Trace: [19172.939273] [<ffffffff802adc37>] bad_page+0x57/0x90 [19172.939280] [<ffffffff8020b92f>] free_hot_cold_page+0x7f/0x180 [19172.939287] [<ffffffff80207a90>] unmap_vmas+0x450/0x750 [19172.939308] [<ffffffff80212867>] unmap_region+0xb7/0x160 [19172.939318] [<ffffffff80211918>] do_munmap+0x238/0x2f0 [19172.939325] [<ffffffff802656c5>] __down_write_nested+0x35/0xf0 [19172.939334] [<ffffffff80215ffd>] sys_munmap+0x4d/0x80 [19172.939341] [<ffffffff8025f11e>] system_call+0x7e/0x83 ------------------------------- Aparently due to the PG_reserved bit set. So my question is: What is currently a proper way to do all this cleanly? Thanks, Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
