How come the Windows DDK samples do not deal with being paged out? Are they non-pageable?
Asked
Active
Viewed 1,139 times
0
-
1I think you need to give more information regarding your use case - which kernel api etc? Or you can read http://msdn.microsoft.com/en-us/library/ff554346.aspx – LordDoskias Sep 24 '11 at 20:13
-
@LordDoskias: can you edit that link to be not version specific? – John Saunders Sep 24 '11 at 20:16
-
1Yes. Pageable code is marked with #pragma code_seg("PAGE") – Hans Passant Sep 24 '11 at 20:27
3 Answers
1
Pageable code is marked with #pragma code_seg("PAGE"). That's why the drivers are not dealing with paging. They are by default all non-pagable.
unixman83
- 9,421
- 10
- 68
- 102
-
That doesn't mean driver code doesn't deal with paging. Pragmas define pageable parts during compilation. And there is also an API to lock/unlock pages at runtime. There are severe restrictions on what can be pageable in kernel. – SomeWittyUsername Oct 26 '12 at 00:39
0
Paged code is wrapped by #pragma code_seg("PAGExxx"), paged data by #pragma data_seg("PAGExxx"). It's also possible to specify paged functions (only c-linkage) with #pragma alloc_text. Classes can also be paged by using declspec(allocate()) starting with WDK 8. There is also an API to lock and unlock pages in memory, allowing runtime control. See more here: http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/ba75e766-6a8f-4fe8-9d03-b69be85655d9
SomeWittyUsername
- 18,025
- 3
- 42
- 85
0
Not speaking specifically of Windows drivers, but only for device drivers in general:
Don't have large drivers.
Don't do that much work in kernel mode and certainly don't do that much work at high interrupt priority levels. Do only what's needed at these levels, then delegate the rest of the work to code that runs at the lowest level (0).
John Saunders
- 160,644
- 26
- 247
- 397
-
Yours is not the first network stack, did you know that? The answer is the same: most of that code needs to not be executing at DISPATCH_LEVEL. – John Saunders Sep 24 '11 at 20:20
-
Sorry, I don't understand this comment. By, "large" do you mean, "complex" or, "large in image size"? If you mean, "complex" then that's hard to quantify. They shouldn't be more complex than they need to be, but isn't that true for all software? If you mean, "large in image size" then I'm not sure how that matters whether the code is in user mode or kernel mode, they're going to take up the same amount of physical memory. And what *is* "too large" these days? NTFS.sys is 1.6MB on my dev system with 16GB of RAM. Also, I'm not sure what the original question has to do with interrupt priorities. – snoone Sep 26 '11 at 14:36