How to judge a routine pageable?

NTDEV
21

kuangnuzhiren@163.com wrote:

So can I get a conclusion : if my code is paged out to the disk, when it is needed to execute, the code can be paged back, then my code is pageable, otherwise it is nonpageable?

The problem is that there are two different concepts involved here, and
there is a tendency to be a little loose with the terminology.

At compile time, you can use compiler directives to tell the compiler
whether a particular function is allowed to be paged out or not. In
that sense, a function is either pageable or non-pageable. Similarly,
when you call ExAllocatePool, you can specify whether the memory you get
back is allowed to be paged out or not. Same concept.

When your code runs, the current IRQL determines whether your code can
HANDLE a page fault or not. If you are running at PASSIVE_LEVEL, and
your code touches a piece of memory that is paged out (code or data),
then everything still works fine. Your thread gets suspended until the
page fault is handled and the code or data is brought back in, at which
point you continue running.

But if you are running at a raised IRQL, like DISPATCH_LEVEL, and your
code touches a piece of memory that is paged out, you get a blue screen
(either IRQL_NOT_LESS_OR_EQUAL or PAGE_FAULT_IN_NONPAGED_AREA).

One of the things that makes this tricky is that pageable code is not
necessarily paged out. So, you can be at a raised IRQL and call into a
function that is marked at pageable, and it might work just fine, most
of the time. Sooner or later, however, the stars will be in
misalignment so that your function really is paged out, and you’ll get a
BSOD. Another tricky thing is that it isn’t always obvious what leads
to a raised IRQL. If you grab a spinlock, you are at a raised IRQL. If
you are in an IRP completion routine, you are at a raised IRQL.

So, here’s the takeaway. For each function and data item, you need to
ask yourself, “is there a possibility that I will need to call this
function or access this piece of data at a raised IRQL?” If the answer
is “yes”, then you must make that function or data item non-pageable.
Otherwise, you can make it pageable (although it isn’t strictly
necessary to do so).

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

22

> But can you explain how can I know whether a disk device is in the paging path or not?

IRP_MN_DEVICE_USAGE_NOTIFICATION

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

23

> One of the things that makes this tricky is that pageable code is not

necessarily paged out. So, you can be at a raised IRQL and call into
a
function that is marked at pageable, and it might work just fine, most
of the time.

The verifier is good at catching this - it pages out memory when you
raise IRQL so that if you do try to touch that memory it fails straight
away, rather than failing occasionally for your customers.

James

24

Tim Roberts wrote:

If you are in an IRP completion routine, you are at a raised IRQL.

I don’t think this is always the case, is it? Maybe from some hardware device that finished in the context of a DPC…

25

I believe you are APC_LEVEL

Paul
----- Original Message -----
From: “chris aseltine”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 13, 2009 10:24:30 PM GMT -05:00 US/Canada Eastern
Subject: RE:[ntdev] How to judge a routine pageable?

Tim Roberts wrote:

> If you are in an IRP completion routine, you are at a raised IRQL.

I don’t think this is always the case, is it? Maybe from some hardware device that finished in the context of a DPC…

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

26

It’s not always true that IRP completion routines are invoked at
DISPATCH_LEVEL. But they can be, and you have to be prepared to handle
that. Since any stack may have a filter inserted into it, you can’t know
whether lower-layer drivers will complete IRPs at PASSIVE_LEVEL.

–
Jake Oshins
Hyper-V I/O Architect
Windows Kernel Group

This post implies no warranties and confers no rights.

wrote in message news:xxxxx@ntdev…
> Tim Roberts wrote:
>
>> If you are in an IRP completion routine, you are at a raised IRQL.
>
> I don’t think this is always the case, is it? Maybe from some hardware
> device that finished in the context of a DPC…
>

27

> In 16 years I’ve never felt the need to do this (pagable functions) to any driver routine.

Agreed. Besides, going through a driver and sprinkling directives on every possible function that can be pagable to be pagable creates a mine field of problems. As maintenance iterations occur over time and by various people, routines marked pagable may accidentally get called directly or indirectly in cases where they cause the rare and hard to find bsod. That’s not worth it nor is the overhead of constantly keeping all the functions up to date on pagability. From a customer standpoint rock solid reliability and time to market comes first, the outside chance of saving a memory page second. It seems the idea behind pagable functions was that once upon a time DriverEntry was quite a big function that always ran exactly once and could be discarded. With PnP drivers DriverEntry should be tiny.

28

You are confusing pagable functions with INIT functions. The latter is discarded and never paged back in. Pagable code will matter again when you driver runs in many VMs on the machine and it has to scale and the VMs are under memory pressure and overcommitted on memory

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@gmail.com
Sent: Friday, August 14, 2009 5:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to judge a routine pageable?

> In 16 years I’ve never felt the need to do this (pagable functions) to any driver routine.

Agreed. Besides, going through a driver and sprinkling directives on every possible function that can be pagable to be pagable creates a mine field of problems. As maintenance iterations occur over time and by various people, routines marked pagable may accidentally get called directly or indirectly in cases where they cause the rare and hard to find bsod. That’s not worth it nor is the overhead of constantly keeping all the functions up to date on pagability. From a customer standpoint rock solid reliability and time to market comes first, the outside chance of saving a memory page second. It seems the idea behind pagable functions was that once upon a time DriverEntry was quite a big function that always ran exactly once and could be discarded. With PnP drivers DriverEntry should be tiny.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

29

Not likely true. You are at the IRQL of whomever called IoCompleteRequest. This is typically done in a dpc (which means dispatch_level), dispatch routine (irql can vary but is usually passive or dispatch), or work item (passive). There are very few situations where the completor will be at APC_LEVEL.

Note that the user mode thread is notified of io completion via an APC, but that is an impl detail that can (and already has) change over different releases

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Paul Sanders
Sent: Thursday, August 13, 2009 10:46 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] How to judge a routine pageable?

I believe you are APC_LEVEL

Paul
----- Original Message -----
From: “chris aseltine”
To: “Windows System Software Devs Interest List”
Sent: Thursday, August 13, 2009 10:24:30 PM GMT -05:00 US/Canada Eastern
Subject: RE:[ntdev] How to judge a routine pageable?

Tim Roberts wrote:

> If you are in an IRP completion routine, you are at a raised IRQL.

I don’t think this is always the case, is it? Maybe from some hardware device that finished in the context of a DPC…

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

30

FYI there has been a lot of work done in the static tools (PFD/SDV) that can detect bugs in paging/irql level. This will help reduce some of the dev costs associated with using pagable routines.

Brandon

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, August 14, 2009 4:16 AM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] How to judge a routine pageable?

You are confusing pagable functions with INIT functions. The latter is discarded and never paged back in. Pagable code will matter again when you driver runs in many VMs on the machine and it has to scale and the VMs are under memory pressure and overcommitted on memory

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: xxxxx@gmail.com
Sent: Friday, August 14, 2009 5:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How to judge a routine pageable?

> In 16 years I’ve never felt the need to do this (pagable functions) to any driver routine.

Agreed. Besides, going through a driver and sprinkling directives on every possible function that can be pagable to be pagable creates a mine field of problems. As maintenance iterations occur over time and by various people, routines marked pagable may accidentally get called directly or indirectly in cases where they cause the rare and hard to find bsod. That’s not worth it nor is the overhead of constantly keeping all the functions up to date on pagability. From a customer standpoint rock solid reliability and time to market comes first, the outside chance of saving a memory page second. It seems the idea behind pagable functions was that once upon a time DriverEntry was quite a big function that always ran exactly once and could be discarded. With PnP drivers DriverEntry should be tiny.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

31

First of all

a)you dont care abt paging or non paging…when using a API…u care abt the irql level…
b)also rem that whenever you acquire a lock…the portion of the code between KeAcquire… and KeRelease is at dispatch level…so you need to take care that that portion is not paged out …
c)Paging IO flag of the IRP says that right now paging operation is being done…so in that patht you do not page fault…else a fatal cascaded PF may arise…

32

> c)Paging IO flag of the IRP says that right now paging operation is being done…so in that patht you

do not page fault…else a fatal cascaded PF may arise…

True for pagefiles only, for mapped usual files, it is OK to take PFs.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com