linux-kernel - Re: [PATCH] x86_64: Dynamically allocate arch specific system vectors

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: <m11w18tmb1.fsf@frodo.ebiederm.org>
Date:	Fri, 01 Aug 2008 15:14:42 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alan Mayer <ajm@....com>
Cc:	Cliff Wickman <cpw@....com>, jeremy@...p.org,
	rusty@...tcorp.com.au, suresh.b.siddha@...el.com, mingo@...e.hu,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Dean Nelson <dcn@....com>
Subject: Re: [PATCH] x86_64:  Dynamically allocate arch specific system vectors

Alan Mayer <ajm@....com> writes:

> Okay, I think we have it now.  assign_irq_vector *almost* does what we need.
> One minor thing is that assign_irq_vector ANDs against cpu_online_map.  We would
> need cpu_possible_map, so we get the vector on offline cpus that may come
> online.  The other thing is that assign_irq_vector doesn't allow the
> specification of interrupt priorities.  It would need to be modified to handle
> returning either a high priority vector or a low priority vector.  Would
> modifying the api for assign_irq_vector be the proper approach?

I don't know if it makes sense to modify assign_irq_vector or to 
have a companion function that uses the same data structures.

I think I would work on the companion function and if the code
can be made sufficiently similar merge the two functions.

> The interrupts don't necessarily fire on all cpus, it's just that they *can*
> fire on any cpu.  For example, the GRU triggers an interrupt (it is very
> IPI'ish) to a particular cpu in the event of a GRU TLB fault. That cpu handles
> the fault and returns.  But the fault can happen on any cpu, so all cpus need to
> be registered for the same vector and irq. This is probably splitting hairs; it
> is certainly no different in principal from timer interrupts or processor TLB
> faults.

Reasonable.  As long as you don't need to read a status register to figure
out what to do that sounds reasonable.  This does sound very much like
splitting hairs on a very platform specific capability.

If we can generalize the mechanism to things like per cpu timer
interrupts and such so that we reduced the total amount of code we
have to maintain I would find it a very compelling mechanism.

> As far as kernel_stat is concerned.  I see you're point.  NR_CPUS on our
> machines is going to be big (4K? 8K? something like that).  NR_IRQS is also
> going to big because of that.  It's unfortunate since the actual number of
> interrupt sources is going to be an order of magnitude smaller, at least.

The number of interrupts sources is going to be smaller only because
SGI machines have or at least appear to have poor I/O compared to most
of the rest of machines in existence.  NR_CPUS*16 is a fairly
reasonable estimate on most machines in existence.  In the short term
it is going to get worse in the presence of MSI-X.  I was talking to a
developer at Intel last week about 256 irqs for one card.  I keep
having dreams about finding a way to just keep stats for a few cpus
but alas I don't think that is going to happen.  Silly us.

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