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 laten
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 dev
вівторок 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 DEVICE_
середа 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...
>
>
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 t
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 t
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 [...]
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 pe
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
> happen
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
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
___
freebsd-stable@f
вівторок 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
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 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 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
понеділок 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 dua
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
dump-t
17 matches
Mail list logo