Epoll based interrupt controller.
IMPROVES: IO loop performance - no per fd lookups, allowing for
15% IO speedup in minimal config going to 100s of % with many
devices - a N^N lookup is now replaced by a log(N)
ADDS: True Write IRQ functionality
OBSOLETES: The need to call reactivate_fd() in any
It throws a couple of harmless "epoll del fd" warnings on reboot which
result the fact that disable_fd/enable_fd are not removed in the
terminal/line code.
These are harmless and will go away once the term/line code gets support
for real write IRQs in addition to read at some point in the futur
Thomas Mayer found a couple of issues which crept up when porting v1 to
the newer kernels.
It also crashes with his config - I am analyzing the differences between
that and mine to find the culrpit.
Once I have fixed both I will resubmit v3. So for now this is just
"subject for discussion", do
On Tue, Nov 10, 2015 at 7:42 PM, Anton Ivanov
wrote:
> Thomas Mayer found a couple of issues which crept up when porting v1 to
> the newer kernels.
>
> It also crashes with his config - I am analyzing the differences between
> that and mine to find the culrpit.
>
> Once I have fixed both I will re
Am Montag, den 09.11.2015, 15:03 + schrieb Anton Ivanov:
> It throws a couple of harmless "epoll del fd" warnings on reboot
> which
> result the fact that disable_fd/enable_fd are not removed in the
> terminal/line code.
>
> These are harmless and will go away once the term/line code gets
>
On Wed, Nov 11, 2015 at 9:46 PM, Thomas Meyer wrote:
> Am Montag, den 09.11.2015, 15:03 + schrieb Anton Ivanov:
>> It throws a couple of harmless "epoll del fd" warnings on reboot
>> which
>> result the fact that disable_fd/enable_fd are not removed in the
>> terminal/line code.
>>
>> These ar
I do not see it with my config. I have cleaned up a few things and can
send an updated version.
At the same time it is 100% reproducible using the config I got from
Thomas. So this is somehow config dependent.
I have compared the configs and the biggest difference I can see is that
Thomas has
> I will probably add some "manual" debug code to check if the nested
> invocation happens with the debug options off.
Might be timing dependent and/or issue with nested blocking/unblocking
of signals.
Or debug printing when it should not.
Just my two cents
Stian Skjelstad
---
There is for some reason IRQ/sigio handler reentrancy.
Both the debug "by hand" I stuck into irq.c and Thomas traces confirm it.
I have no clue how this is possible as the code in signal.c should guard
against that.
I will sleep on it and try to tackle this tomorrow - no idea what is
going on,
On 11/11/15 21:05, Richard Weinberger wrote:
> On Wed, Nov 11, 2015 at 9:46 PM, Thomas Meyer wrote:
>> Am Montag, den 09.11.2015, 15:03 + schrieb Anton Ivanov:
>>> It throws a couple of harmless "epoll del fd" warnings on reboot
>>> which
>>> result the fact that disable_fd/enable_fd are not r
[snip]
>> Hmmm, UML is UP and does not support PREEMPT, so all spinlocks
>> should be a no-op.
> In that case, if I understand correctly what is going on, there are a
> couple of places - the free_irqs(), activate_fd and the sigio handler
> itself, where it should not be a mutex, not a spinlock. I
On 12/11/15 15:23, Anton Ivanov wrote:
> [snip]
>
>>> Hmmm, UML is UP and does not support PREEMPT, so all spinlocks
>>> should be a no-op.
>> In that case, if I understand correctly what is going on, there are a
>> couple of places - the free_irqs(), activate_fd and the sigio handler
>> itself, wh
On 12/11/15 16:03, Anton Ivanov wrote:
> On 12/11/15 15:23, Anton Ivanov wrote:
>> [snip]
>>
Hmmm, UML is UP and does not support PREEMPT, so all spinlocks
should be a no-op.
>>> In that case, if I understand correctly what is going on, there are a
>>> couple of places - the free_irqs(),
Hi all,
I have looked through this and I still have not figured it out
completely. Moving from the old poll controller to the new epoll one
triggers deep recursive invocations of the interrupt handlers. I still
do not understand why it does it so I will park it for now and come back
to it next
14 matches
Mail list logo
