Hello,
Even though we try to minimize calls to KeGetCurrentProcessorNumber, someone has to do it at least once at the top of the IO stack of our code 
I wondered is someone knows how ‘expensive’ is this call i.e. cpu cycles, cash flushing and so on(if applied).
Thanks,
Shay
It’s very cheap.
You could have figure that out yourself, by the way. That function is
inlined and fully defined in the public headers.
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…
Hello,
Even though we try to minimize calls to KeGetCurrentProcessorNumber, someone
has to do it at least once at the top of the IO stack of our code
I wondered is someone knows how ‘expensive’ is this call i.e. cpu cycles,
cash flushing and so on(if applied).
Thanks,
Shay
xxxxx@emc.com wrote:
Even though we try to minimize calls to KeGetCurrentProcessorNumber,
someone has to do it at least once at the top of the IO stack of our
codeI wondered is someone knows how ‘expensive’ is this call i.e. cpu
cycles, cash flushing and so on(if applied).
I despair that the youth of today do not know how to search include
files, or disassemble code.
That call is a macro that expands to exactly one CPU instruction.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I despair that the youth of today do not know how to search include
files, or disassemble code.
And how could we expect anything else when the experienced of the world are
so willing to give of their time to just answer the questions …
Such a quandary. Learning has been replaced largely with ‘searching’ or
asking for an answer. No need to retain the knowledge. It can be found
again on demand.
I believe Tim still deservedly holds onto the “most Saintly patient” list
position despite is momentary lapse into despair.
Dave Cattley
And the social media model that Microsoft forums created just adds to
the problem. Tell someone to look at an API and they decide you don’t
have “the answer”, give them a crappy piece of code and you do have “the
answer” or if they get frustrated, they finally take your API suggestion
and work it out, then reward themselves for giving “the answer”.
Social media is fine for friends and even for business relationships,
but for technical questions it just supports poor development.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“David R. Cattley” wrote in message
news:xxxxx@ntdev:
>
> I despair that the youth of today do not know how to search include
> files, or disassemble code.
>
>
> And how could we expect anything else when the experienced of the world are
> so willing to give of their time to just answer the questions …
>
> Such a quandary. Learning has been replaced largely with ‘searching’ or
> asking for an answer. No need to retain the knowledge. It can be found
> again on demand.
>
> I believe Tim still deservedly holds onto the “most Saintly patient” list
> position despite is momentary lapse into despair.
>
> Dave Cattley
Social media is fine for nothing except mediocre or base things. Since
there is no royal road to geometry, then why one might think there is a
plebeian one to programming astonishes. More on point perhaps, is the
danger of a little learning; advising to drink deep or not at all of that
Empyrean spring seems to loose many
“Don Burn” wrote in message news:xxxxx@ntdev…
And the social media model that Microsoft forums created just adds to
the problem. Tell someone to look at an API and they decide you don’t
have “the answer”, give them a crappy piece of code and you do have “the
answer” or if they get frustrated, they finally take your API suggestion
and work it out, then reward themselves for giving “the answer”.
Social media is fine for friends and even for business relationships,
but for technical questions it just supports poor development.
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
“David R. Cattley” wrote in message
news:xxxxx@ntdev:
>
> I despair that the youth of today do not know how to search include
> files, or disassemble code.
>
>
> And how could we expect anything else when the experienced of the world
> are
> so willing to give of their time to just answer the questions …
>
> Such a quandary. Learning has been replaced largely with ‘searching’ or
> asking for an answer. No need to retain the knowledge. It can be found
> again on demand.
>
> I believe Tim still deservedly holds onto the “most Saintly patient” list
> position despite is momentary lapse into despair.
>
> Dave Cattley
> I despair that the youth of today do not know how to search include files, or disassemble code…
…largely because the are actively discouraged from doing so, don’t you think…
Normally, any advice to check the public headers, let alone disassemble code on this list is more than likely to be followed by dozens of warning about “dangers of relying upon undocumented features that are subjects to a change without notice”, no matter in which context it was given and no matter whether such a warning applies in a particular case. Therefore, there is nothing to be surprised about, let alone to despair - the OP seems to be doing what he is actively encouraged to do, i.e. looking for an “official” info …
Anton Bassov
That is a bit over the top Anton. The header files are the documented
interfaces, as far as I am concerned. What people are warned against doing
is using the undocumented interfaces - the ones that are not documented in
the include files published in the WDK.
Mark Roddy
On Tue, Aug 23, 2011 at 5:58 AM, wrote:
>
> > I despair that the youth of today do not know how to search include
> files, or disassemble code…
>
> …largely because the are actively discouraged from doing so, don’t you
> think…
>
>
> Normally, any advice to check the public headers, let alone disassemble
> code on this list is more than likely to be followed by dozens of warning
> about “dangers of relying upon undocumented features that are subjects to a
> change without notice”, no matter in which context it was given and no
> matter whether such a warning applies in a particular case. Therefore, there
> is nothing to be surprised about, let alone to despair - the OP seems to be
> doing what he is actively encouraged to do, i.e. looking for an “official”
> info …
>
>
> Anton Bassov
>
>
> —
> 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
>
> The header files are the documented interfaces, as far as I am concerned.
???
Look - there are PLENTY of structures that are declared in public headers but are either not fully documented
(DEVICE_OBJECT is the very first example that gets into one’s head - it has some opaque fields like
NextDevice ), or just totally opaque (for example, almost nothing in NDIS.H is supposed to be accessed directly by drivers)…
Anton Bassov
On 22-Aug-2011 22:44, Tim Roberts wrote:
I despair that the youth of today do not know how to search include
files, or disassemble code.
Some of them do know. But those who know apparently work
on other kinds of projects these days…
–pa
xxxxx@hotmail.com wrote:
???
Look - there are PLENTY of structures that are declared in public headers but are either not fully documented (DEVICE_OBJECT is the very first example that gets into one’s head - it has some opaque fields like NextDevice ), or just totally opaque (for example, almost nothing in NDIS.H is supposed to be accessed directly by drivers)…
Your argument is just silly. You’re trying to argue that, because there
a few fields in the header files that are not “fully documented”,
therefore no one should ever look to the header files for reference
information.
The OP was trying to look for the implementation details of a single
documented function. The thinking should have been “is this a macro or
a function”, and “if it is a function, what is the code?” The first
question is obviously answered in the include files, the second by WinDbg.
Regardless of the personal axes you have to grind, it’s only good
engineering practice to use your resources.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> Look - there are PLENTY of structures that are declared in public headers but are either not fully documented
More so, there are some API sets like the rundown protection object which is in the WDK headers and NOT in the docs.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> Your argument is just silly. You’re trying to argue that, because there a few fields in the header files
that are not “fully documented”, therefore no one should ever look to the header files
for reference information.
No,Tim, this is not my argument - this is the argument of those (I don’t want to mention names) who claim that the only reliable source of info is MSDN documentation. In fact, I even vaguely recall a thread where I advised the poster to check the header, and was immediately reminded by one of those folks that any info
in headers that is not documented should not be used. Never mind…
Anton Bassov
This is my own opinion, not an official statement of my employer.
Your driver should only depend on the documented behavior of the OS. If the documentation is inadequate, you can ask Microsoft to fix it; I like to think that Microsoft is decent about continually improving the docs. There are times when there’s a gap in the docs and you need to make an engineering decision, as professional, on what is the best thing to do for our mutual customers.
But all’s fair in love and debugging. When debugging, you can rummage through headers, disassemble routines, and do whatever it takes to root-cause issues. (Microsoft even helps you do that by sharing public symbol files with a fair amount of information in them). Just, please, ensure that knowledge of undocumented behavior you gain while debugging doesn’t become an assumption into your shipping code. So, I don’t mind if you do “dt ndis!_NDIS_MINIPORT_BLOCK ” to figure out something that’s missing from !ndiskd.miniport [although I’m happy to improve !ndiskd if you send me your suggestions], but I throw a fit when I come across drivers that hardcode offsets into that structure [beyond what the legacy NDIS 5.x macros from ndis.h do]). The NDIS team has put more undocumented info in NDIS.PDB in each release of Windows (even Win7 SP1 added a few new types), solely because we want you to be successful at debugging.
So the original question - is KeGetCurrentProcessorNumber “fast”? Well, it’s not documented precisely how many CPU cycles this routine will require. Does Microsoft guarantee that it will be precisely one instruction on x86, or that it will take precisely x CPU cycles? No (and that’s fine – x86 is so out-of-order, a precise cycle count doesn’t mean much in isolation.) But as a professional engineer, you can reason that making it 1000x slower would be a breaking change, of sorts, in the NT ABI. Plus, at a higher level, you can reason that the kernel team knows that this routine is very useful for very fast per-processor data structures, and so they’d be tremendously unwilling to break that use-case by changing the routine to be 1000x times slower. So it’s probably safe to conclude that the routine will continue to be “fast enough” for the lifetime of your driver.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, August 23, 2011 2:31 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How ‘Expensive’ is KeGetCurrentProcessorNumber
> Your argument is just silly. You’re trying to argue that, because
> there a few fields in the header files that are not “fully
> documented”, therefore no one should ever look to the header files for reference information.
No,Tim, this is not my argument - this is the argument of those (I don’t want to mention names) who claim that the only reliable source of info is MSDN documentation. In fact, I even vaguely recall a thread where I advised the poster to check the header, and was immediately reminded by one of those folks that any info in headers that is not documented should not be used. Never mind…
Anton Bassov
—
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
You seem just to confirm what I had earlier said - as I can see, according to you, directly using fields of _NDIS_MINIPORT_BLOCK (which, IIRC, happens to be a public structure declared in ndis.h) is, in terms of stupidity, exactly the same thing as hardcoding offsets (that were obtained from debug symbols) into totally opaque structures that are not exposed via WDK headers ( like ETHREAD, for example) …
Anton Bassov
Ah well if that is what we did out here: only depend on the WDK docs -
nothing much would have gotten done outside of redmond over the last 20
years.
The docs have certainly improved but remain incomplete and inaccurate.
Mark Roddy
On Tue, Aug 23, 2011 at 8:11 PM, Jeffrey Tippet <
xxxxx@microsoft.com> wrote:
This is my own opinion, not an official statement of my employer.
Your driver should only depend on the documented behavior of the OS. If
the documentation is inadequate, you can ask Microsoft to fix it; I like to
think that Microsoft is decent about continually improving the docs. There
are times when there’s a gap in the docs and you need to make an engineering
decision, as professional, on what is the best thing to do for our mutual
customers.But all’s fair in love and debugging. When debugging, you can rummage
through headers, disassemble routines, and do whatever it takes to
root-cause issues. (Microsoft even helps you do that by sharing public
symbol files with a fair amount of information in them). Just, please,
ensure that knowledge of undocumented behavior you gain while debugging
doesn’t become an assumption into your shipping code. So, I don’t mind if
you do “dt ndis!_NDIS_MINIPORT_BLOCK ” to figure out something
> that’s missing from !ndiskd.miniport [although I’m happy to improve !ndiskd
> if you send me your suggestions], but I throw a fit when I come across
> drivers that hardcode offsets into that structure [beyond what the legacy
> NDIS 5.x macros from ndis.h do]). The NDIS team has put more undocumented
> info in NDIS.PDB in each release of Windows (even Win7 SP1 added a few new
> types), solely because we want you to be successful at debugging.
>
> So the original question - is KeGetCurrentProcessorNumber “fast”? Well,
> it’s not documented precisely how many CPU cycles this routine will require.
> Does Microsoft guarantee that it will be precisely one instruction on x86,
> or that it will take precisely x CPU cycles? No (and that’s fine – x86 is
> so out-of-order, a precise cycle count doesn’t mean much in isolation.) But
> as a professional engineer, you can reason that making it 1000x slower would
> be a breaking change, of sorts, in the NT ABI. Plus, at a higher level, you
> can reason that the kernel team knows that this routine is very useful for
> very fast per-processor data structures, and so they’d be tremendously
> unwilling to break that use-case by changing the routine to be 1000x times
> slower. So it’s probably safe to conclude that the routine will continue to
> be “fast enough” for the lifetime of your driver.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
> Sent: Tuesday, August 23, 2011 2:31 PM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] How ‘Expensive’ is KeGetCurrentProcessorNumber
>
> > Your argument is just silly. You’re trying to argue that, because
> > there a few fields in the header files that are not “fully
> > documented”, therefore no one should ever look to the header files for
> reference information.
>
> No,Tim, this is not my argument - this is the argument of those (I don’t
> want to mention names) who claim that the only reliable source of info is
> MSDN documentation. In fact, I even vaguely recall a thread where I advised
> the poster to check the header, and was immediately reminded by one of those
> folks that any info in headers that is not documented should not be used.
> Never mind…
>
>
> Anton Bassov
>
> —
> 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
>
Sorry for the confusion – I picked a messy example. The miniport block is only partially exposed in ndis.h. There’s a private region that is not in the header, and is only exposed through NDIS.PDB. I was referring to that. Some unscrupulous drivers hardcode that. I’m not so worried if your code directly touches a public field (like Miniport->SendCompleteHandler) without using the wrapper macro (like NdisMSendComplete). If you do that, then you mostly only cause headaches for yourself (documentation and analysis are broken; you don’t pick up macro improvements in future WDK releases; etc.). But it’s not a big problem for our customers or the NDIS team, since the ABI is guaranteed on macroized fields.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Tuesday, August 23, 2011 7:41 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] How ‘Expensive’ is KeGetCurrentProcessorNumber
You seem just to confirm what I had earlier said - as I can see, according to you, directly using fields of _NDIS_MINIPORT_BLOCK (which, IIRC, happens to be a public structure declared in ndis.h) is, in terms of stupidity, exactly the same thing as hardcoding offsets (that were obtained from debug symbols) into totally opaque structures that are not exposed via WDK headers ( like ETHREAD, for example) …
Anton Bassov
—
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
I did my take on the headers and undocumented years ago in my blog, see
http://msmvps.com/blogs/windrvr/archive/2007/05/27/crossing-the-undocumented-line.aspx
Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Anton,
Let me point out that once we’ve published something in a header file as an
inline function, we can never change it. There will always be drivers out
there that will contain the inlined code.
So while it’s certainly true that there are things in header files which
aren’t documented, you’re making an interesting logical leap when you say
that people shouldn’t look at the header files. The original poster was
asking how much the function cost. If it can never change, then looking at
the implementation in the header is an excellent way to know what it costs.
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…
The header files are the documented interfaces, as far as I am concerned.
???
Look - there are PLENTY of structures that are declared in public headers
but are either not fully documented
(DEVICE_OBJECT is the very first example that gets into one’s head - it has
some opaque fields like
NextDevice ), or just totally opaque (for example, almost nothing in NDIS.H
is supposed to be accessed directly by drivers)…
Anton Bassov
Jake,
So while it’s certainly true that there are things in header files which aren’t documented,
you’re making an interesting logical leap when you say that people shouldn’t look at the header files.
Please look at my reply to Tim - it is not ME who makes such claims that are, indeed, just illogical in some cases. As you must know, I have always claimed and done exactly the opposite (we did have quite a few “disagreements” here, did not we).
In fact, I think it is just impossible to understand some areas of Windows programming (like NDIS, for example)
without looking at header files, as well as without disassembling code…
Anton Bassov