On Wed, 13 May 2009, Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> > Andi Kleen wrote:
> > > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> > >> Andi Kleen wrote:
> > >>
> > >>> network packets are normally processed by the network packet int
On Wed, May 13, 2009 at 01:44:59PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> >> Andi Kleen wrote:
> >>
> >>> network packets are normally processed by the network packet interrupt's
> >>> softirq or alternatively in the NAPI
Andi Kleen wrote:
> On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
>> Andi Kleen wrote:
>>
>>> network packets are normally processed by the network packet interrupt's
>>> softirq or alternatively in the NAPI poll loop.
>> If we have a high priority task, ksoftirqd may not get a cha
On Wed, May 13, 2009 at 01:04:09PM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
>
> > network packets are normally processed by the network packet interrupt's
> > softirq or alternatively in the NAPI poll loop.
>
> If we have a high priority task, ksoftirqd may not get a chance to run.
In thi
Andi Kleen wrote:
> network packets are normally processed by the network packet interrupt's
> softirq or alternatively in the NAPI poll loop.
If we have a high priority task, ksoftirqd may not get a chance to run.
My point is simply that the documentation says that softirqs are
processed on ret
On Wed, May 13, 2009 at 09:05:01AM -0600, Chris Friesen wrote:
> Andi Kleen wrote:
> > Thomas Gleixner writes:
>
> >>Err, no. Chris is completely correct:
> >>
> >>if (!in_interrupt())
> >>wakeup_softirqd();
> >
> > Yes you have to wake it up just in case, but it doesn't norm
Thomas Gleixner wrote:
> On Wed, 13 May 2009, Chris Friesen wrote:
>> As far as I can tell, in this scenario softirqs may not get processed on
>> return from a syscall (contradicting the documentation). In the worst
>> case, they may not get processed until the next timer tick.
>
> Right because
On Wed, 13 May 2009, Chris Friesen wrote:
> Andi Kleen wrote:
> > Thomas Gleixner writes:
>
> >>Err, no. Chris is completely correct:
> >>
> >>if (!in_interrupt())
> >>wakeup_softirqd();
> >
> > Yes you have to wake it up just in case, but it doesn't normally
> > process the
Andi Kleen wrote:
> Thomas Gleixner writes:
>>Err, no. Chris is completely correct:
>>
>>if (!in_interrupt())
>> wakeup_softirqd();
>
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It's
> just a
Andi Kleen a écrit :
> Thomas Gleixner writes:
>
>
>> Err, no. Chris is completely correct:
>>
>> if (!in_interrupt())
>> wakeup_softirqd();
>
> Yes you have to wake it up just in case, but it doesn't normally
> process the data because a normal softirq comes in faster. It'
> I have one machine SMP flooded by network frames, CPU0 handling all
Yes that's the case softirqd is supposed to handle. When you
spend a significant part of your CPU time in softirq context it kicks
in to provide somewhat fair additional CPU time.
But most systems (like mine) don't do that.
-
On Wed, 13 May 2009, Andi Kleen wrote:
> > "If a soft irq is raised in process context, raise_softirq() in
> > kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
>
> softirqd is only used when the softirq runs for too long or when
> there are no suitable irq exits for a long tim
Thomas Gleixner writes:
> Err, no. Chris is completely correct:
>
> if (!in_interrupt())
> wakeup_softirqd();
Yes you have to wake it up just in case, but it doesn't normally
process the data because a normal softirq comes in faster. It's
just a safety policy.
You can ch
> "If a soft irq is raised in process context, raise_softirq() in
> kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
softirqd is only used when the softirq runs for too long or when
there are no suitable irq exits for a long time.
In normal situations (not excessive time in so
Andi Kleen wrote:
> "Chris Friesen" writes:
>
>>One of the reasons I brought up this issue is that there is a lot of
>>documentation out there that says "softirqs will be processed on return
>>from a syscall". The fact that it actually depends on the scheduler
>>parameters of the task issuing th
"Chris Friesen" writes:
>
> One of the reasons I brought up this issue is that there is a lot of
> documentation out there that says "softirqs will be processed on return
> from a syscall". The fact that it actually depends on the scheduler
> parameters of the task issuing the syscall isn't ever
Hi.
On Tue, May 12, 2009 at 11:12:58AM +0200, Peter Zijlstra
(a.p.zijls...@chello.nl) wrote:
> Wouldn't the even better solution be to get rid of softirqs
> all-together?
And move tasklets into some thread context?
Only if we are ready to fix 7 times rescheduling regressions compared to
kernel
From: Paul Mackerras
Date: Wed, 13 May 2009 15:15:34 +1000
> David Miller writes:
>
>> I fully expected us to be, at this point, talking about putting the
>> pending softirq check back into the trap return path :-/
>
> Would that actually do any good, in the case where the system has
> decided
David Miller writes:
> I fully expected us to be, at this point, talking about putting the
> pending softirq check back into the trap return path :-/
Would that actually do any good, in the case where the system has
decided that ksoftirqd is handling soft irqs at the moment?
Paul.
__
From: Steven Rostedt
Date: Tue, 12 May 2009 08:20:51 -0400 (EDT)
> I'm going to be playing around with bypassing the net-rx/tx with my
> network drivers. I'm going to add threaded irqs for my network cards and
> have the driver threads do the work to get through the tcp/ip stack.
>
> I'll stil
From: Ingo Molnar
Date: Tue, 12 May 2009 11:23:48 +0200
>> Wouldn't the even better solution be to get rid of softirqs
>> all-together?
>>
>> I see the recent work by Thomas to get threaded interrupts
>> upstream as a good first step towards that goal, once the RX
>> processing is moved to a
Ingo Molnar wrote:
> * Chris Friesen wrote:
>>I think I see a possible problem with this. Suppose I have a
>>SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT set. Under
>>the scenario above, schedule() would re-run the spinning task
>>rather than ksoftirqd, thus preventing any incoming
On Tue, 12 May 2009, Peter Zijlstra wrote:
> On Tue, 2009-05-12 at 11:23 +0200, Ingo Molnar wrote:
> >
> > Yeah, that would be "nice". A single IRQ thread plus the process
> > context(s) doing networking might perform well.
> >
> > Multiple IRQ threads (softirq and hardirq threads mixed) i'm
On Tue, 2009-05-12 at 11:23 +0200, Ingo Molnar wrote:
>
> Yeah, that would be "nice". A single IRQ thread plus the process
> context(s) doing networking might perform well.
>
> Multiple IRQ threads (softirq and hardirq threads mixed) i'm not so
> sure about - it's extra context-switching cost.
On Tue, 2009-05-12 at 10:12 +0200, Ingo Molnar wrote:
> * Chris Friesen wrote:
>
> > This started out as a thread on the ppc list, but on the
> > suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> > list a bit.
> >
> > Currently, if a softirq is raised in process context the
* Peter Zijlstra wrote:
> On Tue, 2009-05-12 at 10:12 +0200, Ingo Molnar wrote:
> > * Chris Friesen wrote:
> >
> > > This started out as a thread on the ppc list, but on the
> > > suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> > > list a bit.
> > >
> > > Currently, if a
* Chris Friesen wrote:
> This started out as a thread on the ppc list, but on the
> suggestion of DaveM and Paul Mackerras I'm expanding the receiver
> list a bit.
>
> Currently, if a softirq is raised in process context the
> TIF_RESCHED_PENDING flag gets set and on return to userspace we
This started out as a thread on the ppc list, but on the suggestion of
DaveM and Paul Mackerras I'm expanding the receiver list a bit.
Currently, if a softirq is raised in process context the
TIF_RESCHED_PENDING flag gets set and on return to userspace we run the
scheduler, expecting it to switch
Chris Friesen writes:
> Suppose I have a SCHED_FIFO task spinning on recvmsg() with MSG_DONTWAIT
> set (and maybe doing other stuff if there are no messages). In this
> case, schedule() would re-run the spinning task rather than running
> ksoftirqd. This could prevent any incoming packets from act
From: "Chris Friesen"
Date: Mon, 11 May 2009 12:25:54 -0600
> David Miller wrote:
>
>> You know, for networking over loopback (one of the only real cases
>> that even matters, if we get a hard interrupt then the return from
>> that would process any softints), we probably make out just fine
>> a
David Miller wrote:
> You know, for networking over loopback (one of the only real cases
> that even matters, if we get a hard interrupt then the return from
> that would process any softints), we probably make out just fine
> anyways. As long as we hit a local_bh_enable() (and in the return
> pa
From: Paul Mackerras
Date: Sat, 9 May 2009 13:31:23 +1000
> David Miller writes:
>
>> Grumble, when did that happen :-(
>
> Ages ago (i.e. before the switch to git :). Talk to Ingo, it's his
> doing IIRC.
I'll first do some data mining before coming to any (further)
conclusions :-)
>> That's
David Miller writes:
> Grumble, when did that happen :-(
Ages ago (i.e. before the switch to git :). Talk to Ingo, it's his
doing IIRC.
> That's horrible for latency compared to handling it directly
> in the trap return path.
Actually, I don't know why we ever let there be softirqs pending whe
> > The soft irq stuff is pretty much all generic code these days, except
> > for the code to switch to the softirq stack.
>
> Grumble, when did that happen :-(
>
> That's horrible for latency compared to handling it directly
> in the trap return path.
If it is indeed such a problem, it would b
Paul Mackerras wrote:
If a soft irq is raised in process context, raise_softirq() in
kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
runs soon to process the soft irq. So what would happen is that we
would see the TIF_RESCHED_PENDING flag on the current task in the
syscall
From: Paul Mackerras
Date: Sat, 9 May 2009 09:34:29 +1000
> If a soft irq is raised in process context, raise_softirq() in
> kernel/softirq.c calls wakeup_softirqd() to make sure that ksoftirqd
> runs soon to process the soft irq. So what would happen is that we
> would see the TIF_RESCHED_PENDI
Chris Friesen writes:
> I'm trying to figure out where exactly softirqs are called on return
> from a syscall in 64-bit powerpc. I can see where they get called for a
> normal interrupt via the irq_exit() path, but not for syscalls.
If a soft irq is raised in process context, raise_softirq() i
From: "Chris Friesen"
Date: Fri, 08 May 2009 16:51:25 -0600
> I'm trying to figure out where exactly softirqs are called on return
> from a syscall in 64-bit powerpc. I can see where they get called for
> a normal interrupt via the irq_exit() path, but not for syscalls.
>
> I'm sure I'm missing
Hi all,
I'm trying to figure out where exactly softirqs are called on return
from a syscall in 64-bit powerpc. I can see where they get called for a
normal interrupt via the irq_exit() path, but not for syscalls.
I'm sure I'm missing something obvious...can anyone help?
Thanks,
Chris
_
39 matches
Mail list logo
