linux-kernel - Re: [PATCH 2/3] x86: x2apic/cluster: Make use of lowest priority delivery mode

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]

Message-ID: <20120521145904.GA7068@gmail.com>
Date:	Mon, 21 May 2012 16:59:04 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Alexander Gordeev <agordeev@...hat.com>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 2/3] x86: x2apic/cluster: Make use of lowest priority
 delivery mode

* Alexander Gordeev <agordeev@...hat.com> wrote:

> > So I think we need to tread carefully here.
> 
> Kernel parameter? IRQ line flag? Totally opposed? :)

Undecided and sceptical, because: -ENONUMBERS :-)

The kernel actually tries to have as much locality as we can 
hide from the user.

For example we don't execute tasks for 100 usecs on one CPU, 
then jump to another CPU and execute 100 usecs there, then to 
yet another CPU to create an 'absolutely balanced use of CPU 
resources'. Why? Because the cache-misses would be killing us.

When a device is generating ten thousand irqs a second then 
round-robining the IRQs is equivalent to switching a CPU every 
100 usecs.

There's another cost: tasks tend to try to migrate to sources of 
wakeups. So if an IRQ wakes up a task then we will try to 
execute the task locally, to have locality of access between the 
data that the IRQ handler has touched, and the task that makes 
use of it. Round-robining the IRQ in that situations means that 
the task either follows the IRQ and round-robins (bad), or that 
it stays remote to the IRQ data (not good either).

So, I'm sceptical :-/

Your other two patches looked sensible - will they apply fine 
after each other, without the round-robin patch which is still 
under discussion, or is there a dependency?

Thanks,

	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/