On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote:
> So if you want to invest some time into getting this into mergeable
> shape I'd suggest you redo the patch series in the following way:
>
> patch 1: dynamic allocated irq stacks
Can we register them lazily at request_irq time?
--
Mathematics is the supreme nostalgia of our time.
On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote:
>> So if you want to invest some time into getting this into mergeable
>> shape I'd suggest you redo the patch series in the following way:
>> patch 1: dynamic allocated irq stacks
On Tue, May 01, 2007 at 05:36:06PM -0500, Matt Mackall wrote:
> Can we register them lazily at request_irq time?
These IRQ stacks are per-cpu, not per-IRQ. It may make sense to
implement per-IRQ stacks, in which case dynamic allocation at the time
of request_irq() will make sense.
Would you like me to implement per-IRQ IRQ stacks?
-- wli
> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to
> implement per-IRQ stacks, in which case dynamic allocation at the time
> of request_irq() will make sense.
This depends if active IRQ count exceeds active CPU count worst cases.
For the big boxes it might well do but for small ones we seem to be best
with per CPU.
Alan
On Tue, May 01, 2007 at 03:51:25PM -0700, Bill Irwin wrote:
> On Mon, Apr 30, 2007 at 08:15:11PM +0100, Christoph Hellwig wrote:
> >> So if you want to invest some time into getting this into mergeable
> >> shape I'd suggest you redo the patch series in the following way:
> >> patch 1: dynamic allocated irq stacks
>
> On Tue, May 01, 2007 at 05:36:06PM -0500, Matt Mackall wrote:
> > Can we register them lazily at request_irq time?
>
> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to
> implement per-IRQ stacks, in which case dynamic allocation at the time
> of request_irq() will make sense.
>
> Would you like me to implement per-IRQ IRQ stacks?
It's probably the "right" thing to do, but it does have higher
overhead for most systems.
But it also gives a very obvious migration path to -rt's irq threads.
--
Mathematics is the supreme nostalgia of our time.
At some point in the past, I wrote:
>> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to
>> implement per-IRQ stacks, in which case dynamic allocation at the time
>> of request_irq() will make sense.
On Wed, May 02, 2007 at 12:07:45AM +0100, Alan Cox wrote:
> This depends if active IRQ count exceeds active CPU count worst cases.
> For the big boxes it might well do but for small ones we seem to be best
> with per CPU.
I'll leave IRQ stacks per-CPU, then. The prevailing opinion on large
i386 does not favor doing much of anything to accommodate it.
-- wli
On Tue, May 01, 2007 at 05:36:06PM -0500, Matt Mackall wrote:
>>> Can we register them lazily at request_irq time?
On Tue, May 01, 2007 at 03:51:25PM -0700, Bill Irwin wrote:
>> These IRQ stacks are per-cpu, not per-IRQ. It may make sense to
>> implement per-IRQ stacks, in which case dynamic allocation at the time
>> of request_irq() will make sense.
>> Would you like me to implement per-IRQ IRQ stacks?
On Tue, May 01, 2007 at 06:15:48PM -0500, Matt Mackall wrote:
> It's probably the "right" thing to do, but it does have higher
> overhead for most systems.
> But it also gives a very obvious migration path to -rt's irq threads.
Well, I don't really know how much of -rt or which pieces of it are
really going in. Otherwise it favors large-scale i386, which people
largely want to ignore/break/etc. I'll err on the side of caution and
not change it.
-- wli