I’m working on a minifilter that does some reparse point handling. It
doesn’t need to do anything on CREATE, but on READ or WRITE it needs to
have the reparse data available to it. Solution: A cache that holds
onto the data. The question here is: Should I keep one cache shared
globally across all instances of the minifilter, or should I put it in
the instance context?
The MSDN tells you how to use instance contexts, but doesn’t seem to
cover when it is desirable to do so. As near as I can tell, the issue
boils down to the following points:
The cache will be queried on every read and write (and close). Is there
a big hit for calling FltGetInstanceContext when I’m not actually going
to need any of the other stuff already in it?
The problem, obviously, isn’t as simple as just that though. Creates
and closes are writers of the cache, reads/writes are readers of the
cache. If you have a cache per instance, there should be less
contention for the locks under load. (Secondary question, each instance
is attached to a volume, the code I inheritted uses instance contexts,
not volume contexts, is this recommended? Is one preferable over the
other apart from the restriction that volume contexts have to come from
the non-paged pool?)
At the moment, it’s worth noting that I don’t have any performance data
either way, so I’m not looking for an answer based on whether or not
this will specifically make my application faster, just a good rule of
thumb or set of guidelines. I’d lean towards implementing whichever is
more “correct” and clean at the moment over a potentially negligible
performance increase.
Thanks,
~Eric
Topical quote:
“Until we have a working piece of code, we don’t always know
where it spends its time. And until we know that, talk of changing it
‘for efficiency’ is foolish.” - Brian Kernighan and P. J. Plauger