Minor improvements in kernel - user communications

NTFSD
1

I’m curious to see what people might have to say on this…

WRT a mini-filter sending messages to a user app to get acceptance for
some sort of activity, I know that the very act of sending the message
is very costly in terms of throughput, CPU usage, etc.

Given that the message must be sent, what is more efficient…

Sending 64 and 32-bit values, even if they’re known to be small (i.e. <=
8 bits) and Unicode strings or

Compacting things into byte size data and converting to 8-bit characters
(assuming no character set issues)

In the first case, you send many bytes of data but you don’t waste CPU
time doing a lot of non-machine-native data size manipulations. In the
second, you substantially reduce the numbers of bytes per message –
perhaps to less than half.

Is this worth thinking about or is it just a tempest in a teapot?

Regards,
Mickey.

2

If these are relatively infrequent (e.g., < 1 per second), the CPU usage and
overhead of any of the methods you suggest is probably insignificant.

IMHO,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey Lane
Sent: Friday, August 26, 2005 3:31 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Minor improvements in kernel - user communications

I’m curious to see what people might have to say on this.

WRT a mini-filter sending messages to a user app to get acceptance for
some sort of activity, I know that the very act of sending the message
is very costly in terms of throughput, CPU usage, etc.

Given that the message must be sent, what is more efficient.

Sending 64 and 32-bit values, even if they’re known to be small (i.e. <=
8 bits) and Unicode strings or

Compacting things into byte size data and converting to 8-bit characters
(assuming no character set issues)

In the first case, you send many bytes of data but you don’t waste CPU
time doing a lot of non-machine-native data size manipulations. In the
second, you substantially reduce the numbers of bytes per message -
perhaps to less than half.

Is this worth thinking about or is it just a tempest in a teapot?

Regards,
Mickey.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

In my situation, I’m filtering both the file system and the registry.
Most of the time, the registry activity outweighs the file system
activity - sometimes by an order of magnitude.

At the moment, I’m seeing a very large variation in duty cycle if you
will. I can find groups of seconds where nothing at all happens followed
by as many as a thousand messages per second (a guess - I haven’t counted).

As you might guess, reducing the need to send the message at all is a
big deal right now…

Mickey.

Ken Cross wrote:

If these are relatively infrequent (e.g., < 1 per second), the CPU usage and
overhead of any of the methods you suggest is probably insignificant.

IMHO,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey Lane
Sent: Friday, August 26, 2005 3:31 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Minor improvements in kernel - user communications

I’m curious to see what people might have to say on this.

WRT a mini-filter sending messages to a user app to get acceptance for
some sort of activity, I know that the very act of sending the message
is very costly in terms of throughput, CPU usage, etc.

Given that the message must be sent, what is more efficient.

Sending 64 and 32-bit values, even if they’re known to be small (i.e. <=
8 bits) and Unicode strings or

Compacting things into byte size data and converting to 8-bit characters
(assuming no character set issues)

In the first case, you send many bytes of data but you don’t waste CPU
time doing a lot of non-machine-native data size manipulations. In the
second, you substantially reduce the numbers of bytes per message -
perhaps to less than half.

Is this worth thinking about or is it just a tempest in a teapot?

Regards,
Mickey.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@earthlink.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

I don’t think that compacting actual data that you exchange between KM
and UM may have significant impact on performance. The method that you
choose to perform that exchange may. For example, you will have to
choose between 3 IOCTL methods to pull data from KM to UM: buffered,
direct or neither . AFAIK, all of them are well documented in terms of
which one use for what and what are the cost of using each one.
Besides, the actual result may also vary depending on what exactly you
are reporting to the UM. For example, if you’re reporting CREATE irps
then time you spent on reporting itself is relatively insignificant
comparing with the time spent in the entire create handler. If you are
reporting each READ (most of which can come from the cache) this could
be very significant.
Here is my experience. I report each CREATE (both, successful and not),
first QueryDir (with potentially lot of data coming from the app), each
delete and rename that occur on the entire disk drive. Along with other
things that I do in my filter this cuts 7-10% from the overall
performance, where about 3% goes towards KM-UM overhead and 4-7% -
“additional stuff” that I do in my driver. Of course your mileage may
vary, but 3% is not that significant number which you can’t
significantly reduce anyway :slight_smile:

Vladimir Chtchetkine

Principal Engineer

Borland Software is the global leader in platform independent solutions
for Software Delivery Optimization, helping customers address the
constraints of modern day software development to maximize the business
value of their software.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mickey Lane
Sent: Friday, August 26, 2005 12:31 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Minor improvements in kernel - user communications

I’m curious to see what people might have to say on this…

WRT a mini-filter sending messages to a user app to get acceptance for
some sort of activity, I know that the very act of sending the message
is very costly in terms of throughput, CPU usage, etc.

Given that the message must be sent, what is more efficient…

Sending 64 and 32-bit values, even if they’re known to be small (i.e. <=
8 bits) and Unicode strings or

Compacting things into byte size data and converting to 8-bit characters
(assuming no character set issues)

In the first case, you send many bytes of data but you don’t waste CPU
time doing a lot of non-machine-native data size manipulations. In the
second, you substantially reduce the numbers of bytes per message -
perhaps to less than half.

Is this worth thinking about or is it just a tempest in a teapot?

Regards,
Mickey.

Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as:
xxxxx@borland.com To unsubscribe send a blank email to
xxxxx@lists.osr.com