* What's the concern about setting irq thread's policy as SCHED_FIFO
@ 2014-12-03 8:06 Qin Chuanyu
2014-12-03 16:51 ` Rick Jones
0 siblings, 1 reply; 3+ messages in thread
From: Qin Chuanyu @ 2014-12-03 8:06 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
I am doing network performance test under suse11sp3 and intel 82599 nic,
Becasuse the softirq is out of schedule policy's control, so netserver
thread couldn't always get 100% cpu usage, then packet dropped in kernel
udp socket's receive queue.
In order to get a stable result, I did some patch in ixgbe driver and
then use irq_thread instead of softirq to handle rx.
It seems work well, but irq_thread's SCHED_FIFO schedule policy cause
that when the cpu is limited, netserver couldn't work at all.
So I change the irq_thread's schedule policy from SCHED_FIFO to
SCHED_NORMAL, then the irq_thread could share the cpu usage with
netserver thread.
the question is:
What's the concrete reason about setting irq thread's policy as SCHED_FIFO?
Except the priority affecting the cpu usage, any function would be
broken if irq thread change to SCHED_NORMAL?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: What's the concern about setting irq thread's policy as SCHED_FIFO
2014-12-03 8:06 What's the concern about setting irq thread's policy as SCHED_FIFO Qin Chuanyu
@ 2014-12-03 16:51 ` Rick Jones
2014-12-04 3:12 ` Qin Chuanyu
0 siblings, 1 reply; 3+ messages in thread
From: Rick Jones @ 2014-12-03 16:51 UTC (permalink / raw)
To: Qin Chuanyu, netdev; +Cc: linux-kernel
On 12/03/2014 12:06 AM, Qin Chuanyu wrote:
> I am doing network performance test under suse11sp3 and intel 82599 nic,
> Becasuse the softirq is out of schedule policy's control, so netserver
> thread couldn't always get 100% cpu usage, then packet dropped in kernel
> udp socket's receive queue.
>
> In order to get a stable result, I did some patch in ixgbe driver and
> then use irq_thread instead of softirq to handle rx.
> It seems work well, but irq_thread's SCHED_FIFO schedule policy cause
> that when the cpu is limited, netserver couldn't work at all.
I cannot speak to any scheduling issues/questions, but can ask if you
tried binding netserver to a CPU other than the one servicing the
interrupts via the -T option on the netperf command line:
netperf -T <netperfCPU>,<netserverCPU> ...
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dT_002c-Global-41
happy benchnmarking,
rick jones
>
> So I change the irq_thread's schedule policy from SCHED_FIFO to
> SCHED_NORMAL, then the irq_thread could share the cpu usage with
> netserver thread.
>
> the question is:
> What's the concrete reason about setting irq thread's policy as SCHED_FIFO?
> Except the priority affecting the cpu usage, any function would be
> broken if irq thread change to SCHED_NORMAL?
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: What's the concern about setting irq thread's policy as SCHED_FIFO
2014-12-03 16:51 ` Rick Jones
@ 2014-12-04 3:12 ` Qin Chuanyu
0 siblings, 0 replies; 3+ messages in thread
From: Qin Chuanyu @ 2014-12-04 3:12 UTC (permalink / raw)
To: Rick Jones, netdev; +Cc: linux-kernel
On 2014/12/4 0:51, Rick Jones wrote:
> On 12/03/2014 12:06 AM, Qin Chuanyu wrote:
>> I am doing network performance test under suse11sp3 and intel 82599 nic,
>> Becasuse the softirq is out of schedule policy's control, so netserver
>> thread couldn't always get 100% cpu usage, then packet dropped in kernel
>> udp socket's receive queue.
>>
>> In order to get a stable result, I did some patch in ixgbe driver and
>> then use irq_thread instead of softirq to handle rx.
>> It seems work well, but irq_thread's SCHED_FIFO schedule policy cause
>> that when the cpu is limited, netserver couldn't work at all.
>
> I cannot speak to any scheduling issues/questions, but can ask if you
> tried binding netserver to a CPU other than the one servicing the
> interrupts via the -T option on the netperf command line:
>
> netperf -T <netperfCPU>,<netserverCPU> ...
>
> http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dT_002c-Global-41
>
Yes, I had done this try, the irq_thread and netserver worked well
without competition after binding them separately.
I also had tried this test case in kernel 3.10, and without binding
irq_thread and netserver work well separately.
So, the question is:
3.10: irq_thread netserver good
3.0.93: irq_thread netserver bad(compete single cpu)
normal thread in both kernel version is OK.
There must be a schedule policy change lead to this difference.
Could anyone give some hint?
>
> happy benchnmarking,
>
> rick jones
>
>>
>> So I change the irq_thread's schedule policy from SCHED_FIFO to
>> SCHED_NORMAL, then the irq_thread could share the cpu usage with
>> netserver thread.
>>
>> the question is:
>> What's the concrete reason about setting irq thread's policy as
>> SCHED_FIFO?
>> Except the priority affecting the cpu usage, any function would be
>> broken if irq thread change to SCHED_NORMAL?
>>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-12-04 3:12 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-03 8:06 What's the concern about setting irq thread's policy as SCHED_FIFO Qin Chuanyu
2014-12-03 16:51 ` Rick Jones
2014-12-04 3:12 ` Qin Chuanyu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).