Question about memory mapping mechanism

[Martin Drab]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/