On 26 Jan 2011, at 21:14, m...@freebsd.org wrote:

>> The kinds of cases I worry about are things like the tcp connection 
>> monitoring sysctls. Most systems have a dozen, hundred, or a thousand 
>> connections. Some have half a million or a million. If we switched to 
>> requiring wiring every page needed to store that list, it would do terrible 
>> things to the system. So really what I have in mind is: either we handle 
>> cases like that well, or we put in a clear warning and have obvious failure 
>> modes to catch the cases where it didn't work out. In practice, I think we 
>> would not want to switch the tcpcb/inpcb sysctl for this reason, but as 
>> people say "ah, this is convenient" we need to make sure it's handled well, 
>> and easy to debug problems when they do arise.
> 
> But I think that problem exists today using sysctl for output, since
> it's non-iterative.  In fact, it's often worse today, because in
> addition to the user-space buffer that needs to be large enough to
> hold the output, the kernel needs to malloc(9) a buffer to hold it
> before doing the one SYSCTL_OUT at the end that most routines I've
> seen use.
> 
> For situations like this where there is a lot of output but it doesn't
> need to be serialized by a lock held across the whole data fetch, then
> yes, using sbuf_new_for_sysctl() would wire more memory.

Right -- hence my concern about (a) appropriate documentation and (b) proper 
error handling. The sbuf routine looks convenient, easy to use, and exactly the 
semantic that I want in most cases. However, sometimes, it may silently break 
based on something rather abstract getting "too big". We need users of the KPI 
to be aware of that limitation and hence not use it when that could occur, and 
when it does occur, generate a clear notice of some sort so that it can be 
tracked down.

Robert_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to