* RE: process starvation with 2.6 scheduler
@ 2006-06-05 23:05 Kallol Biswas
2006-06-06 17:09 ` Thiago Galesi
0 siblings, 1 reply; 2+ messages in thread
From: Kallol Biswas @ 2006-06-05 23:05 UTC (permalink / raw)
To: linuxppc-dev
Some more information:
For the active process:
Last_ran 0x190458787
Timestamp: 0x190458787
For the starved process:
Last_ran: 0x14dc18cfd
Timestamp: 0x14dc18cfd
-----Original Message-----
From: Kallol Biswas
Sent: Monday, June 05, 2006 3:09 PM
To: 'linuxppc-dev@ozlabs.org'
Subject: FW: process starvation with 2.6 scheduler
-----Original Message-----
From: Kallol Biswas
Sent: Monday, June 05, 2006 2:30 PM
To: Kallol Biswas; linux-kernel@vger.kernel.org
Subject: RE: process starvation with 2.6 scheduler
I have checked the per processor run queue data structure (we have only one).
The active process is the in the queue list 118 of the of array[0] and the
starved process is the queue list 120 of the array[0]. The pointer, active points to array[0] and expired points to array[1].
-----Original Message-----
From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Kallol Biswas
Sent: Monday, June 05, 2006 1:47 PM
To: linux-kernel@vger.kernel.org
Subject: process starvation with 2.6 scheduler
From: Kallol Biswas
Sent: Monday, June 05, 2006 12:49 PM
To: 'linux-kernel@vger.kernel.org'
Subject: process starvation with 2.6 scheduler
Hello,
We have a process starvation problem with our 2.6.11 kernel running on a ppc-440 based system.
We have a storage SOC based on PPC-440. The SOC is emulated on a system emulator called Palladium. It is from Cadence. The system runs at 400KHz speed. It has three Ethernet ports; they are connected to outside lab network with a speed bridge.
The netperf server netserver runs on the emulated system (2.6.11 kernel on Palladium). There are netperf linux clients running on a x86 box.
If netperf request response (TCP_RR) traffic is run on all three ports; after sometime only one port remains active, the application (netperf client) on other two ports wait for a long time and eventually time out.
The netserver code has been instrumented. For one of the starved netserver processes it has been found that the TCP_RR request from the netperf client on linux x86 box has been received by the server, it has issued send() call to send back reply but send() never returns.
With an ICE connected to the Palladium (emulator) I have dumped the kernel data structures of the starved process and the active process.
For Active Process:
Time_slice 84
Policy : SCHED_NORMAL
Dynamic priority: 118
Static priority: 120
Preempt_count: 0x20100
Thread_info->flags = 0
State = 0 (TASK_RUNNING)
For Starved Process:
Time slice: 77
Policy: SCHED_NORMAL
Dynamic priority: 120
Static priority: 120
Preempt_count: 0x10000000 (PREEMPT_ACTIVE is set)
Thread_info->flags = 0
State = 0 (TASK_RUNNING)
CONFIG_PREEMPT is not set.
The system has single CPU.
Any help to debug the problem is welcome.
Kallol
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: process starvation with 2.6 scheduler
2006-06-05 23:05 process starvation with 2.6 scheduler Kallol Biswas
@ 2006-06-06 17:09 ` Thiago Galesi
0 siblings, 0 replies; 2+ messages in thread
From: Thiago Galesi @ 2006-06-06 17:09 UTC (permalink / raw)
To: Kallol Biswas; +Cc: linuxppc-dev
Did you try it with a _real_ CPU? My bet is that the timer interrupt
is overwhelming the CPU (even at 100Hz, 400kHz is too slow).
--
-
Thiago Galesi
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2006-06-06 17:09 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-06-05 23:05 process starvation with 2.6 scheduler Kallol Biswas
2006-06-06 17:09 ` Thiago Galesi
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).