Pradeep wrote:
> Interestingly after killing the application (iperf in this case) , all the
> buffers are returned back and detach went through fine. I cant figure it
> out whether its issue with iperf or streams framework
You're seeing exactly what I described: if an application doesn't clear
out its buffers, it can hang onto them "forever."
It's not that it's a problem with either of those things. It's really a
problem of expectations. STREAMS expects that all buffers are
essentially "the same," and that there's no particular reason to force
one buffer to be freed any more quickly than another. They're just a
way to hold data, and nothing more, and thus can be queued without
consequence. Applications expect that unread data will remain available
until read, and that the system won't just throw things away as long as
queue limits are respected. The desballoc design expects that the
callback function will remain viable until the buffer is finally freed.
Those expectations collide to produce the sort of hold-down behavior
you're seeing.
The same general problem actually occurs in many different contexts.
For example, mblks have dblks attached, and dblks have cred_t. The
cred_t points to the zone_t, and the zone_t points to the zone's root
path. Thus, you can't unmount a file system containing a zone root
until all of the buffers that were generated within that zone are either
freed or stripped of their cred_t references. And you can't reboot a
zone in that state, either, as that waits on the zone_t to shut down.
If there were a group responsible for STREAMS, it might want to look
into the ways in which the basic STREAMS data structures have been made
interdependent on other structures -- the places where they hold
references. Perhaps there's a basic STREAMS architectural issue to address.
In terms of just desballoc, what I think you need is either:
- A central (genunix) driver resource that handles desballoc, so that
the driver needn't remain loaded while buffers are still outstanding
(and so that each driver doesn't have to write this code from
scratch).
- A mechanism within STREAMS that "un-desballocs" buffers by somehow
detecting or predicting protracted queuing situations, and then
doing the necessary data copies.
Currently, neither exists, but it sounds like someone may be working on
something like the first of those two.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
networking-discuss mailing list
[email protected]
