Hello!
> Soft irqs should definitely not be much heavier than an irq handler,
> if they are then we have implemented them wrongly somehow.
For example, all the networking nicely fits to this class. :-)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, Jun 20, 2001 at 10:18:10PM +1000, Paul Mackerras wrote:
> Well if they are relying on having a lot of stack available then those
> places are buggy. Once the softirq is made pending it can run at any
it's not about having lots of stack available, it's about avoiding
recursion.
Andrea
-
Andrea Arcangeli writes:
> We should release the stack before running the softirq (some place uses
> softirqs to release the stack and avoid overflows).
Well if they are relying on having a lot of stack available then those
places are buggy. Once the softirq is made pending it can run at any
ti
On Wed, Jun 20, 2001 at 01:33:19PM +1000, Paul Mackerras wrote:
> Well, I object to the "without thinking" bit. [..]
agreed, apologies.
> BHs disabled is buggy - why would you want to do that? And if we do
tasklet_schedule
> want to allow that, shouldn't we put the check in raise_softirq or t
Andrea Arcangeli writes:
> With pre3 there are bugs introduced into mainline that are getting
> extended to all architectures.
>
> First of all nucking the handle_softirq from entry.S is wrong. ppc
> copied without thinking and we'll need to resurrect it too for example
Well, I object to the "w
With pre3 there are bugs introduced into mainline that are getting
extended to all architectures.
First of all nucking the handle_softirq from entry.S is wrong. ppc
copied without thinking and we'll need to resurrect it too for example
so please arch maintainers don't kill that check (alpha in pr
6 matches
Mail list logo
