lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 6 Jun 2016 07:03:22 -0500
From:	Clark Williams <williams@...hat.com>
To:	Alison Chaiken <alison@...oton-tech.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-rt-users <linux-rt-users@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH][RT] netpoll: Always take poll_lock when doing polling

On Sun, 5 Jun 2016 08:16:58 -0700
Alison Chaiken <alison@...oton-tech.com> wrote:

> Steven Rostedt suggests in reference to "[PATCH][RT] netpoll: Always
> take poll_lock when doing polling"
> >> [ Alison, can you try this patch ]  
> 
> Sebastian follows up:
> >Alison, did you try it?  
> 
> Sorry for not responding sooner.   I was hoping to come to a complete
> understanding of the system before replying . . .
> 
> I did try that patch, but it hasn't made much difference.   Let me
> back up and restate the problem I'm trying to solve, which is that a
> DRA7X OMAP5 SOC system running a patched 4.1.18-ti-rt kernel has a
> main event loop in user space that misses latency deadlines under the
> test condition where I ping-flood it from another box.   While in
> production, the system would not be expected to support high rates of
> network traffic, but the instability with the ping-flood makes me
> wonder if there aren't underlying configuration problems.

What sort of tunings have you applied, regarding thread and interrupt affinity? If you have not, you might try isolating one of your cores and just run the user-space application on that core, with interrupt threads running on the other core. You could use the 'tuna' application like this:

	$ sudo tuna --cpus=1 --isolate

This will move all the threads that *can* be moved off of cpu1 (probably to cpu0 since I believe the OMAP5 is a dual-core processor?). 

Also, what scheduler policy/priority are you using for the user-space application?

Clark

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists