Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752754AbaLDDMX (ORCPT ); Wed, 3 Dec 2014 22:12:23 -0500 Received: from szxga02-in.huawei.com ([119.145.14.65]:3109 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751429AbaLDDMW (ORCPT ); Wed, 3 Dec 2014 22:12:22 -0500 Message-ID: <547FD10C.8040900@huawei.com> Date: Thu, 4 Dec 2014 11:12:12 +0800 From: Qin Chuanyu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Rick Jones , CC: Subject: Re: What's the concern about setting irq thread's policy as SCHED_FIFO References: <547EC4A3.6060408@huawei.com> <547F3F92.2050501@hp.com> In-Reply-To: <547F3F92.2050501@hp.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.21.101] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 , ... > > 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? >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/