linux-kernel - Re: [PATCH 0/5] Generic smp_call_function(), improvements, and smp_call_function

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:	Thu, 27 Mar 2008 11:08:02 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	linux-kernel@...r.kernel.org, npiggin@...e.de, paulus@...ba.org,
	tglx@...utronix.de, mingo@...hat.com, tony.luck@...el.com
Subject: Re: [PATCH 0/5] Generic smp_call_function(), improvements, and
	smp_call_function_single()


* Jens Axboe <jens.axboe@...cle.com> wrote:

> which is pretty much identical to io-cpu-affinity, except it uses 
> kernel threads for completion.
> 
> The reason why I dropped the kthread approach is that it was slower. 
> Time from signal to run was about 33% faster with IPI than with 
> wake_up_process(). Doing benchmark runs, and the IPI approach won 
> hands down in cache misses as well.

with irq threads we'll have all irq context run in kthread context 
again. Could you show me how you measured the performance of the kthread 
approach versus the raw-IPI approach?

we can do a million kthread context switches per CPU per second, so 
kthread context-switch cost cannot be a true performance limit, unless 
you micro-benchmarked this.

	Ingo
--
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/