linux-kernel - Re: Can context switches be faster?

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:	Fri, 13 Oct 2006 16:47:45 -0700 (PDT)
From:	David Lang <dlang@...italinsight.com>
To:	Andreas Mohr <andi@...x01.fht-esslingen.de>
cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	John Richard Moser <nigelenki@...cast.net>,
	Chris Friesen <cfriesen@...tel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Can context switches be faster?

On Sat, 14 Oct 2006, Andreas Mohr wrote:

> OK, so since we've now amply worked out in this thread that TLB/cache flushing
> is a real problem for context switching management, would it be possible to
> smartly reorder processes on the runqueue (probably works best with many active
> processes with the same/similar priority on the runqueue!) to minimize
> TLB flushing needs due to less mm context differences of adjacently scheduled
> processes?
> (i.e. don't immediately switch from user process 1 to user process 2 and
> back to 1 again, but always try to sort some kernel threads in between
> to avoid excessive TLB flushing)

since kernel threads don't cause flushing it shouldn't matter where they appear 
in the scheduleing.

other then kernel threads, only threaded programs share the mm context (in 
normal situations), and it would be a fair bit of work to sort the list of 
potential things to be scheduled to group these togeather (not to mention the 
potential fairness issues that would arise from this).

I suspect that the overhead of doing this sorting (and looking up the mm context 
to do the sorting) would overwelm the relativly small number of TLB flushes that 
would be saved.

I could see this being a potential advantage for servers with massive numbers of 
threads for one program, but someone would have to look at how much overhead the 
sorting would be (not to mention the fact that the kernel devs tend to frown on 
special case optimizations that have a noticable impact on the general case)

David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/