code_seg / alloc_text pragma - static library
in [Device Drivers]
|
Prev: WinUSB Error 121 - semaphore timeout
Next: STATUS_ACCESS_DENIED causes file deletion (minifilter driver)
From: Alexander Grigoriev on 8 Jan 2010 21:47 Yes. Unless your driver is in the paging path. "Don Burn" <burn(a)stopspam.windrvr.com> wrote in message news:eeSHb7IkKHA.4356(a)TK2MSFTNGP06.phx.gbl... > Gee, it is SO HARD to take a look at call and see if it is called only at > PASSIVE_LEVEL and does not use something like spin locks that raise IRQL. > And then of course once you add the #pragma page and a PAGED_CODE macro > into the driver, it is INCREDIBLY HARD to run PreFast to find out if there > is either a likelyhood the call is not a PASSIVE or that you are using an > IRQL raising function. And of course it is CLOSE TO IMPOSSIBLE to run > the checked version of the driver, and if by chance the analysis was wrong > catch things when the PAGED_CODE macro asserts. > > Personally, I find it IMPOSSIBLE TO UNDERSTAND how people can be so lazy > to not develop the code correctly. > > > -- > Don Burn (MVP, Windows DKD) > Windows Filesystem and Driver Consulting > Website: http://www.windrvr.com > Blog: http://msmvps.com/blogs/WinDrvr > Remove StopSpam to reply > > > > "alberto" <amoreira(a)ieee.org> wrote in message > news:42d9806e-1f8e-4d1d-ba54-527f2f946a44(a)e20g2000vbb.googlegroups.com... > I frankly don't see what's the point. If there's not enough space for > drivers to comfortably use the nonpaged pool for what they need - > without having developers to exercise what I'd call "dirty" > optimization and handicrafted embellishment - then the OS may need to > be revamped, or we may need a bigger machine, or both. > > There's also the issue that no matter how we hack it, 32-bit systems > are limited in what they can handle, and, true enough, by the time the > NP pool runs out of space we may have hit a bottleneck way before. > > Given that it is already complicated enough to write a driver, I > believe that bothering about substituting paged for nonpaged memory > only adds to the complexity - and consequently to the potential > instability - of the code. There are more important things that > require our developer's creative juices. I agree with Alexander that > drivers should not use paged storage, period. If the OS cannot handle > that, let's improve the OS. > > One other point that may not be relevant to many of you but that is > quite relevant to me is the compatibility issue. I just cannot afford > to let nonportable mechanisms to infiltrate my driver, or I'm going to > have a hard time running it on a non-Windows OS. I need a memory > utilization model that is eminently portable between Windows and the > Unixen, else I'm not going to use it! > > Last but not least, "responsible" driver writing is at the eyes of the > beholder. In my line of work, for example, not making strong use of > the system's capabilities to optimize its main mission is not what I > would call "responsible". In fact, to avoid this kind of problem, I > allocate a pretty large chunk of physical memory at init time - > hundreds of megabytes if I can - and I suballocate my memory from > there, and chuck the NP pool. When push comes to shove and what I need > is to make sure that the main mission of the system gets accomplished, > I'm not at all shy of taking control of things in my own hands, and I > call that as "responsible" as it can be - my users come first, the OS > second. > > But hey, I may be wrong. > > Alberto. > > > On Jan 8, 8:29 am, "Don Burn" <b...(a)stopspam.windrvr.com> wrote: >> No the exercise is called responsible driver writting. I have faced with >> a >> bunch of drivers that were poorly written and take much more non-paged >> code >> than they needed to. It is amazing how little work it took once I got the >> source to reduce one drivers foot print by 50%. There will be 32-bit >> systems for a long time, there will be a lot of 64-bit systems with low >> end >> memory systems which limit memory to something small for a much longer >> time. >> >> -- >> Don Burn (MVP, Windows DKD) >> Windows Filesystem and Driver Consulting >> Website:http://www.windrvr.com >> Blog:http://msmvps.com/blogs/WinDrvr >> Remove StopSpam to reply >> >> "Alexander Grigoriev" <al...(a)earthlink.net> wrote in message >> >> news:%23C7XTiBkKHA.4356(a)TK2MSFTNGP06.phx.gbl... >> >> >> >> >> >> > Considering that all new computers are x64 compatible, with memory >> > >=2GB, >> > and most OEMs are shipping x64 flavor installed by default, this >> > exercise >> > can be compared to collecting drops from liquor bottles for a morning >> > hangover fix... Not that I ever did that... >> >> > "Pavel Lebedinsky [MSFT]" <pa...(a)online.microsoft.com> wrote in message >> >news:OwmRwS2jKHA.2132(a)TK2MSFTNGP05.phx.gbl... >> >>> I would call this micro-optimization, rudiment from NT 3.1, which ran >> >>> on 32 MB. I don't argue against paged pool, but paged kernel code >> >>> should just go away. And paged kernel stacks, too >> >> >> If you ask the Windows perf team, they will probably say that >> >> saving 10 MB of nonpaged memory is a major achievement, not a >> >> micro-optimization. >> >> >> During win7 the perf team filed hundreds of bugs against all kinds >> >> of components across Windows (not just drivers), asking them to >> >> reduce nonpaged footprint, copy-on-write pages in user space etc. >> >> Sometimes the savings were just a few pages per component, >> >> but together they are a big part of why win7 is the only version >> >> of Windows (except maybe NT 3.5/3.51) to have a smaller >> >> memory footprint than the previous one. >> >> >>> Better memory usage optimization would be to fix file caching. >> >> >> That's like saying that you shouldn't try to make a plane lighter >> >> until you can figure out how to make the engines more powerful. >> >> Why not try to do both at the same time? >> >> >> -- >> >> Pavel Lebedinsky/Windows Fundamentals Test >> >> This posting is provided "AS IS" with no warranties, and confers no >> >> rights. >> >> > __________ Information from ESET NOD32 Antivirus, version of virus >> > signature database 4753 (20100108) __________ >> >> > The message was checked by ESET NOD32 Antivirus. >> >> >http://www.eset.com >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4753 (20100108) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com- Hide quoted text - >> >> - Show quoted text - > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4754 (20100108) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4754 (20100108) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > >
From: alberto on 12 Jan 2010 14:08 As I said before, compatibility issues alone prevent me from letting things such as IRQLs and PASSIVE_LEVEL to float out of the subarchitectural level. In the 5 to 10% of the driver that's Windows dependent I can splurge on that kind of stuff, but the rest of the driver must not know what things like PASSIVE_LEVEL are all about. That 90% + of the driver must be buildable by GCC as well, and #pragmas that bring in nonportable things are, well, unacceptable. And consider this. I can write a spinlock loop in plain vanilla machine code that is totally portable between Windows, Linux, Solaris and MacOS. Why should I bother using anything else ? That's why I recommended in another post to mask away all his synchronization constructs with macros, so that all that OS-dependent stuff is kept away from the driver's mainstream. Helps debugging, helps compatibility, saves coding. And believe me, I just do not use paged code anywhere in my driver. Does that make it unusable, or "incorrect" ? I don't think so. Right now we're running it in stress mode, uninterrupted, for days, 24/7, calm sea and prosperous voyage. The driver for the current board's predecessor - I didn't write it - doesn't use paged code either, and it has been in production for close to 10 years in a very demanding medical environment. So, hey, it's never as clear cut as it looks! Alberto. On Jan 8, 1:17 pm, "Don Burn" <b...(a)stopspam.windrvr.com> wrote: > Gee, it is SO HARD to take a look at call and see if it is called only at > PASSIVE_LEVEL and does not use something like spin locks that raise IRQL. > And then of course once you add the #pragma page and a PAGED_CODE macro into > the driver, it is INCREDIBLY HARD to run PreFast to find out if there is > either a likelyhood the call is not a PASSIVE or that you are using an IRQL > raising function. And of course it is CLOSE TO IMPOSSIBLE to run the > checked version of the driver, and if by chance the analysis was wrong catch > things when the PAGED_CODE macro asserts. > > Personally, I find it IMPOSSIBLE TO UNDERSTAND how people can be so lazy to > not develop the code correctly.
From: Alexander Grigoriev on 12 Jan 2010 22:47 A spinlock without raising DPC (which can't be done in plain vanilla machine code) won't work. It might cause deadlocks. "alberto" <amoreira(a)ieee.org> wrote in message news:6cc48be6-054a-49b8-9d6b-1e60a2c9cab1(a)d30g2000vbl.googlegroups.com... And consider this. I can write a spinlock loop in plain vanilla machine code that is totally portable between Windows, Linux, Solaris and MacOS. Why should I bother using anything else ? That's why I
From: Scott Noone on 13 Jan 2010 10:28 >A spinlock without raising DPC (which can't be done in plain vanilla >machine code) won't work. It might cause deadlocks. You can write the spinlock and disable all interrupts with cli instead of raising to DISPATCH_LEVEL (not that I recommend this as it unnecessarily negatively impacts the system). -scott -- Scott Noone Consulting Associate OSR Open Systems Resources, Inc. http://www.osronline.com "Alexander Grigoriev" <alegr(a)earthlink.net> wrote in message news:efB7nMAlKHA.2188(a)TK2MSFTNGP04.phx.gbl... >A spinlock without raising DPC (which can't be done in plain vanilla >machine code) won't work. It might cause deadlocks. > > "alberto" <amoreira(a)ieee.org> wrote in message > news:6cc48be6-054a-49b8-9d6b-1e60a2c9cab1(a)d30g2000vbl.googlegroups.com... > > And consider this. I can write a spinlock loop in plain vanilla > machine code that is totally portable between Windows, Linux, Solaris > and MacOS. Why should I bother using anything else ? That's why I > > >
From: alberto on 13 Jan 2010 13:51
If a piece of memory is important enough that it has to be synchronized at interrupt time, it may be important enough that the overhead of locking all processors isn't that big of a deal. In fact, I haven't seen that many situations where optimizing processor performance makes that much difference, unless we're talking about big time scientific or engineering computation. Alberto. On Jan 12, 10:47 pm, "Alexander Grigoriev" <al...(a)earthlink.net> wrote: > A spinlock without raising DPC (which can't be done in plain vanilla machine > code) won't work. It might cause deadlocks. > > "alberto" <amore...(a)ieee.org> wrote in message > > news:6cc48be6-054a-49b8-9d6b-1e60a2c9cab1(a)d30g2000vbl.googlegroups.com... > > And consider this. I can write a spinlock loop in plain vanilla > machine code that is totally portable between Windows, Linux, Solaris > and MacOS. Why should I bother using anything else ? That's why I |