> -----Original Message-----
> From: Leon Pollak [mailto:le...@plris.com]
> Sent: Wednesday, 30 March, 2016 11:05
> To: Jon Maloy
> Cc: tipc-discussion@lists.sourceforge.net
> Subject: Re: [tipc-discussion] kernel page allocation problem
>
> On Wednesday 30 March 2016 14:40:58 Jon Maloy wrote:
> > Hi Leon,
> > I took a quick look at your dump, and to me it looks like you have simply
> run out of memory. I think that is the first thing you should look at.
> > As for the most recent code version to use, I cannot give you aby definite
> answer, since the kernel API and environment keeps changing continuously, so
> new code will not easily compile on older kernels and vice versa.
> > If you want to go down that road, I would recommend a bisectional approach,
> e.g., try if the code from 3.15 applies and runs, and then go forwards or
> backwards from there.
> > But, as already said, look at the problem you have at hand first.
>
>
> Jon, thank you for the answer.
>
> I saw that the problem is in the lack of memory.
> I also made a simple stress test (one side sends in a loop) and received this
> problem immediately.
>
> But User's Manual states that if there is no room for the receiving side to
> accept message it prevents the sending side from sending, effectively blocking
> the sender.
That is true only for connection oriented messaging (SOC_STREAM,
SOCK_SEQPACKET). Is that what you are running?
If you are just doing a tight loop with 66k messages using TIPC_PORT_NAME you
will not have any flow control, and the messages might be dropped in the
receiving socket.
But if you are really tight of memory they might also be dropped at the link
layer, which is what you are seeing.
I have never seen that happening before, but it is fully possible in TIPC
versions before commit 40ba3cdf542a469aaa9 ("tipc: message reassembly using
fragment chain") from Nov 6th 2013. (I don't remember which Linux version this
corresponds to, but that should be easy to find out). Furthermore, this might
even happen with connection oriented messaging, but is less likely.
So, if you are running connectionless, I recommend you to go to a connection
oriented mode. If you already are connection oriented, you can try to find out
which version this fix was in, and re-adapt the code.
Regards
///jon
> This is what I expected to occur. But this doesn't happen in my case.
> I logged the sendto() execution time and it always was less then 2ms, except
> the case when this page error occurred on the accepting side - then sendto()
> took about 500-700 ms.
>
> Excuse me, please, may be this is the simple newbie question...:-)
> What do I do wrong?
>
> --
> Leon
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
