On Fri, 20 May 2005, Grant Grundler wrote:
> Not entirely. One could fill unimplemented values with -1 or 0. or use s-expressions a la supermon. That's worked the best for us in widely varying environments. These fixed-format tables of the type that /proc delivers are painful. > For monitoring performance, a single /sys file that lists all devices > is the lightest weight and is acceptable according to > Documentation/filesystems/sysfs.txt: > > | Attributes should be ASCII text files, preferably with only one value > | per file. It is noted that it may not be efficient to contain only > | value per file, so it is socially acceptable to express an array of > | values of the same type. yes, that is the accepted thing nowadays. And, boy, is it SLOW. SLOW, SLOW, SLOW. Open file, read ONE value, close file. Takes a long time. So we've seen that for a number of values you really can't sample at interesting rates. Of course, you can speed it up a bit -- keep your files open, right? open once, read, fseek 0, read, ... Except then, if you need to unload the module, well, you can't: you have the /sys files open and the module can't really be unloaded. Of course, if you only need values very 10 seconds or so, /sys is ok. But if you're look at 100 or 1khz, monitoring, which we do sometimes here, /sys is entirely inadequate. /sys is wonderful, and all, but it's not for high speed monitoring. If I understood what to look for from the driver better (I lack knowledge in this IB area :-) I could write a supermon kernel module for it. Again, this only matters if you need performance, I'm not sure what people need here. ron _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
