linux-kernel - Re: [PATCH] irq: sparseirq enabling v4

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:	Sat, 29 Nov 2008 15:33:27 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Sam Ravnborg <sam@...nborg.org>,
	"David S. Miller" <davem@...emloft.net>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] irq: sparseirq enabling v4

* Sam Ravnborg <sam@...nborg.org> wrote:

> > very nice!
> > 
> > All the structural feedback i gave seems to be addressed properly, 
> > and the patch has shrunk and consolidated nicely. I think we can 
> > start splitting it up and applying it to tip/irq/sparseirq. We might 
> > notice a few more details when that happens, on a per patch basis.
> 
> Hi Ingo / Yinghai.
> 
> Was the concerns raised by Benjamin, davem, others addressed? Just 
> curious - I have never looked into this part of the kernel.

(Cc:-ed DaveM and BenH)

I cannot speak for them, but my concens have been addressed. AFAICT the 
feedback from non-x86 land centered around two main areas:

  1) the SPARSEIRQ generic IRQ layer changes were ugly and complex

  That was one of my worries too and it has all been made rather elegant, 
  simple and fast via the new irq_desc_ptrs[] approach. (It can also be a
  speedup on NUMA as irq->desc can now host the irq statistics counters,
  etc. - so there will be an incentive for architectures to switch over 
  to sparse irq_desc[], even if they do not plan to support 4096 CPUs or 
  more)

  2) that x86 should do this all via virtual IRQ remapping

  I think this was based on a misunderstanding of what x86 architecture 
  does currently and where it wants to go with these changes.

  Firstly, the x86 architecture already remaps interrupts in a number of 
  areas: it remaps them on certain 32-bit systems via the use of irq 
  compression, and it remaps them for virtual MSI irqs as well. (which 
  are virtual to begin with)

  But the problem is not the ability or inability to remap IRQs on x86 - 
  that can obviously be done (and is being done) in a number of areas 
  when we want to shape or compress the IRQ space more intelligently.

  The problem that is solved here is that we want to enable distros to 
  build a kernel with NR_CPUS and NR_IRQS set to really high numbers 
  (4096 for NR_CPUS and 16K for NR_IRQS), and hence the plain static size 
  of all NR_IRQS arrays in the core kernel become an issue (== megabytes 
  of RAM wasted even on a plain dual core system). No amount of virtual 
  IRQ remapping in architecture code can solve that problem - we had to
  reduce the size of those core kernel arrays.

If there were any other concerns that i missed, please let us know.

	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/