On Tuesday 31 October 2006 20:41, Jack Vogel wrote:
= I still think it looks like some kind of scheduler issue going on
= here, so maybe this is something to check.
Ok. First I tried to cvs the sys/dev/em back to 6.1 -- the new kernel
had the same problems...
Then I tried to change the 'PCI
On Tuesday 31 October 2006 20:41, Jack Vogel wrote:
= I still think it looks like some kind of scheduler issue going on
= here, so maybe this is something to check.
Why would the scheduler affect the sys component of the load (which
shoots to the sky before the machine drops of the network)? I
Mikhail Teterin wrote:
Actually, it stalls even with polling disabled. It just takes A LOT
longer, as I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but
it still happens. Pressing a key still wakes it up...
Sounds like apm or something making the machine go
середа 01 листопад 2006 08:44, Steven Hartland написав:
Actually, it stalls even with polling disabled. It just takes A LOT
longer, as I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but
it still happens. Pressing a key still wakes it up...
Sounds like
вівторок 31 жовтень 2006 19:43, Jack Vogel написав:
This is fairly bizarre :) I think I can say pretty safely that this is NOT
an em driver issue, its a scheduler problem of some sort.
Am I the only one having problems with em driver? In its latest
6.x-incarnation?
Or is the enabled
Mikhail Teterin wrote:
Why would the scheduler affect the sys component of the load (which
shoots to the sky before the machine drops of the network)? I thought,
it only matters for user-space programs (the order in which they run)...
It also schedules internal kernel threads (such as device
понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав:
Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in
kernel, but without polling actialy enabled). The dump got underway,
although the amount of sys load was rather high -- way above 70%
most of the time (on a dual-CPU
On 10/31/06, Mikhail Teterin [EMAIL PROTECTED] wrote:
понеділок 30 жовтень 2006 23:23, Mikhail Teterin написав:
Ok. I rebooted and restarted the heavy traffic dump (DEVICE_POLLING in
kernel, but without polling actialy enabled). The dump got underway,
although the amount of sys load was
вівторок 31 жовтень 2006 13:49, Jack Vogel написав:
Scott's question still hasnt been answered, or if so I dont understand it.
If everything was working why were you trying to turn on polling?
Because it was working poorly -- over 50% of the (combined) CPU time was spent
in the kernel (sys)
On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote:
Nothing -- the screen (console) is not updated. If I leave top(1) running,
I'll see INSANE amounts of CPU-time (1300% each, for example) getting
attributed to the compressing programs -- after that top stops refreshing.
What
вівторок 31 жовтень 2006 14:14, Jeremy Chadwick написав:
On Tue, Oct 31, 2006 at 01:57:54PM -0500, Mikhail Teterin wrote:
Nothing -- the screen (console) is not updated. If I leave top(1)
running, I'll see INSANE amounts of CPU-time (1300% each, for example)
getting attributed to the
Actually, it stalls even with polling disabled. It just takes A LOT longer, as
I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but it still
happens. Pressing a key still wakes it up...
-mi
___
On 10/31/06, Mikhail Teterin [EMAIL PROTECTED] wrote:
Actually, it stalls even with polling disabled. It just takes A LOT longer, as
I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but it still
happens. Pressing a key still wakes it up...
-mi
This
On 10/31/06, Jack Vogel [EMAIL PROTECTED] wrote:
On 10/31/06, Mikhail Teterin [EMAIL PROTECTED] wrote:
Actually, it stalls even with polling disabled. It just takes A LOT longer, as
I just found out.
Instead of minutes, it takes hours of heavey traffict to stall, but it still
happens.
On Tue, 31 Oct 2006 16:46:10 -0800
Jack Vogel [EMAIL PROTECTED] wrote:
So like :
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
Looks like a special option that most probably dont have [...]
This option is in GENERIC, so it is something most people
On 10/31/06, Joerg Pernfuss [EMAIL PROTECTED] wrote:
On Tue, 31 Oct 2006 16:46:10 -0800
Jack Vogel [EMAIL PROTECTED] wrote:
So like :
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
Looks like a special option that most probably dont have [...]
This
Mikhail Teterin wrote:
On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote:
= We aren't currently speaking about performance, we need to know whether
= kernel with DEVICE_POLLING option makes NIC work stable.
Having noticed today's em-driver update, I rebuilt world/kernel and tried the
On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote:
= We aren't currently speaking about performance, we need to know whether
= kernel with DEVICE_POLLING option makes NIC work stable.
Having noticed today's em-driver update, I rebuilt world/kernel and tried the
dump-test again.
The kernel
18 matches
Mail list logo
