On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote: > On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote: > > the reason is that pools now keep track of things that are sleeping > > for memory and will give them an item BEFORE waking them up. > > previously i believe they were woken up to try and get an item, > > which could fail as you described because interrupt load could > > starve sleepers before the wakeup actually happens. > > > > mbufs and clusters are allocated out of pools, so they now inherit > > this behaviour. > > The commit message says: > > "userland process might hang if the system ran out of mbuf clusters" > > As I understand, we are hitting the global mbuf cluster limit. I > don't see how a changed pool wakeup policy could fix this hang. >
Choose your poision. When running out of cluster a userland process doing a write hangs. But to be honest even if the process manages to fill the buffer with just huge mbuf chains the packet sending will probably fail later on in the driver code because we need to call m_defrag() to collaps the scather gather list. Using mbufs without clusters is not a great idea... in fact it may make the situation worse. Long term I hope to be able to decouple the socketbuffers enough from the transport side so that starvation of clusters is not resulting in a network deadlock. -- :wq Claudio
