As far as I know, there are some similar testing in test01 and netstress
of NICDRV.
Robin
Tom Chen:
Miles,
I experienced this issue at test01, not the 15 hour netstress test. Do
you see this issue at test01?
Tom
----- Original Message ----- From: "Min Miles Xu" <[email protected]>
To: "Paul Durrant" <[email protected]>
Cc: "Tom Chen" <[email protected]>;
<[email protected]>
Sent: Friday, February 27, 2009 5:41 AM
Subject: Re: [networking-discuss] no buffer in promiscuous tx/rx?!
Hi,
I think Tom may run into the state of memory exhaustion. I noticed a
similar issue. I filed CR 6806472 The memory is exhausted by allocb()
when running NICdrv netstress.
Regards,
Miles Xu
Paul Durrant wrote:
Tom Chen wrote:
In the NICDrv test01 (promiscuous mode rx/tx test using netperf and
snoop), I noticed that my driver runs out of resources. I am using
"desballoc" to pre- allocate message blocks and the OS should return
data buffer once it consumes the message. It seems that the driver
does not get data buffer back in time and has to rely heavily on
"copy" mode which I used when there are not enough free data buffer
inside driver and has to dynamically allocate new message block using
"allocb", copy new packet to it, then send to OS. But gradually,
machine becomes very slow, probably due to large number of memory
held by OS.
Have you traced through the full lifecycle of some of your buffers
to make sure that you're recycling payload correctly and not leaking
memory yourself. A good way to look for leaks is to do a test run
with kmem_flags set to 0xf then drop into kmdb and do a $<systemdump
to force a panic. When the system reboots you can then do an mdb
::findleaks on the core to check for large numbers of leaked
buffers, and who allocated them.
I am wondering in what condition can this situation happen? why OS
does not return data buffer back to driver quickly? if a packet
driver sent is wong, the OS should discard it immediately and release
the memory, isn't it?
Part of the problem with using desballoc() is that the stack may
hang onto your memory for an arbitrarily long time. When using TCP
there's generally two return scenarious:
- the buffer is returned from the context of the driver receive
handler (possibly because it's just ACKing a TX).
- the buffer is returned from the context of the read() call on the
socket head when the data is copied out to user space and thus the
buffer is no longer needed.
The amount of time taken in the second scenario is clearly heavily
dependent on the app.
Paul
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
