linux-kernel - Re: Context switch latency in tickless isolated CPU

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 linux-hardening linux-cve-announce 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:	Wed, 17 Aug 2016 08:18:59 -0400
From:	Chris Metcalf <cmetcalf@...lanox.com>
To:	GeHao Kang <kanghao0928@...il.com>, <fweisbec@...il.com>,
	<linux-api@...r.kernel.org>, <linux-kernel@...r.kernel.org>
CC:	<peterz@...radead.org>, <tglx@...utronix.de>, <mingo@...nel.org>,
	<paulmck@...ux.vnet.ibm.com>
Subject: Re: Context switch latency in tickless isolated CPU

On 8/17/2016 2:26 AM, GeHao Kang wrote:
> To investigate the cause, I use the kernel event tracer to find out
> the events, user_enter and user_exit, of context_tracking would happen
> on tickless isolated CPU. These two events means that this CPU enters
> and exits the RCU extended quiescent state. Besides, the execution
> time of these two events are 3us and 2us,
> which are measured by ktime. Is this the reason why the context switch
> has higher
> latency on the tickless isolated CPU?

The increased context switch time is likely from the increased
time to return from the kernel to userspace, due to ensuring
that various things in the kernel are quiesced.

Of course I'm sure it goes without saying that context switch
time is probably near the absolute bottom of things that
we care about as a metric for task isolation, since when you
are using it as designed, you never actually context switch.
But that said, it's always good to quantify what the overheads
are, so thanks.

-- 
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com