Messages in this thread | | | Date | Sat, 4 Sep 1999 08:24:58 -0500 (EST) | From | "Mark H. Wood" <> | Subject | Re: /proc/cpuinfo verbiage differ unnecessarily between ports... |
| |
On Sat, 4 Sep 1999, Matthew Wilcox wrote:
> On Fri, Sep 03, 1999 at 12:51:04PM -0500, Mark H. Wood wrote: > > There's still a problem though, if I understand sysctl's argument > > structure: you can only fetch (or set) one thing at a time. That means > > that a monitoring tool could be causing quite a lot of context-switching. > > a syscall isn't a context-switch. I remember hearing someone say that > mingo has patches to bring it down to 30us. That's not a lot :-)
OK, I picked the wrong word. A thing that takes time out to save/restore registers, does evil things to the TLB and the cache, etc. It's worth minimizing these if the cost of doing so isn't too high.
> > A better way would be (say) a sysctln() that would take a whole list of > > items and return them all in a single pair of context switches. > > (*Setting* N items in one call leads to difficulties with partial success, > > so maybe it should be a read-only sysjustshowmen(). :-) > > Like readv/writev?
If you're saying that the arguments would look like a list of iovecs, yes to some extent. There'd have to be another field in the descriptor to specify *what* was wanted, since there'd be no ordering imposed on the items you could ask for. [Crowd murmurs: he's a VMS-head, he's talking about SYS$GETSYI()! Stone him!]
If you're saying that one should just use readv on a handle to some /proc file, no -- people play with the layout of /proc files all the time so there's no good way to know what counts to put in the sortof-iovecs. (Now you know my "other reasons" for doing it this way. You can't be blindsided by encoding and formatting changes if there's no encoding or formatting.)
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu A Brazil-nut is neatly packaged and tightly integrated. To turn it into food, you must crack and remove the shell. I find that I feel the same way about an increasing number of software products. *sigh*
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |