looking for a preempt-patch for 2.4.10-ac12

looking for a preempt-patch for 2.4.10-ac12

[elko]

Where can I find a preempt-patch for Linux-2.4.10-ac12 ?

-- 
ElkOS: 7:52pm up 2 days, 2:34, 3 users, load average: 1.52, 1.47, 1.51
bofhX: sticky bit has come loose
\x04

Re: looking for a preempt-patch for 2.4.10-ac12

[José Luis Domingo López]

On Tuesday, 16 October 2001, at 19:52:44 +0200,
elko wrote:

> 
> Where can I find a preempt-patch for Linux-2.4.10-ac12 ?
> 
http://tech9.net/rml/linux

But there isn't a patch for this specific kernel version, so you will have to
download the most similar one and apply it in the hope of not getting too
much and complex .rej

-- 
José Luis Domingo López
Linux Registered User #189436     Debian Linux Woody (P166 64 MB RAM)
 
jdomingo EN internautas PUNTO org  => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT   org  => Spam at your own risk

Re: looking for a preempt-patch for 2.4.10-ac12

[elko]

On Tuesday 16 October 2001 22:47, José Luis Domingo López wrote:
> On Tuesday, 16 October 2001, at 19:52:44 +0200,
>
> elko wrote:
> > Where can I find a preempt-patch for Linux-2.4.10-ac12 ?
>
> http://tech9.net/rml/linux
>
> But there isn't a patch for this specific kernel version, so you will
> have to download the most similar one and apply it in the hope of not
> getting too much and complex .rej


the patch is there, I applied it together with the stats-patch
and my system is running like a charm right now, never have seen
this kind of response in X.


the only thing is, the perl-script at:
http://www.tech9.net/rml/linux/top-latencies

shows something this:

----[ SNIP ]----
n   min  avg  max  cause   mask start line/file address end line/file
  14 9512 9590 9711  spin_lock 5 2111/tcp_ipv4.c c0226736119/softirq.c
  89 9454 9559 9682  spin_lock 9 2111/tcp_ipv4.c c0226736119/softirq.c
   2 9540 9551 9563  spin_lock 3 2111/tcp_ipv4.c c0226736119/softirq.c
3895 7708 9532 14296 spin_lock 1 2111/tcp_ipv4.c c0226736119/softirq.c
   1 9513 9513 9513  spin_lock 1 2111/tcp_ipv4.c c02267362152/tcp_ipv4.c
 363 3594 6166 9512  spin_lock 0 2111/tcp_ipv4.c c02267362152/tcp_ipv4.c
----[ SNIP ]----

that 3895 number for '2111/tcp_ipv4.c c0226736119/softirq.c'
keeps adding up, how should I translate that? big network
latency, is that what it means? if so, any idea on how
can I fix that??

-- 
ElkOS: 9:18pm up 1:08, 3 users, load average: 2.40, 2.38, 2.28
bofhX: overflow error in /dev/null
\x04

Re: looking for a preempt-patch for 2.4.10-ac12

[Robert Love]

On Wed, 2001-10-17 at 15:47, elko wrote:
> the patch is there, I applied it together with the stats-patch
> and my system is running like a charm right now, never have seen
> this kind of response in X.

Glad everything is working smooth...

> the only thing is, the perl-script at:
> http://www.tech9.net/rml/linux/top-latencies
> 
> shows something this:
> 
> ----[ SNIP ]----
> n   min  avg  max  cause   mask start line/file address end line/file
>   14 9512 9590 9711  spin_lock 5 2111/tcp_ipv4.c c0226736119/softirq.c
>   89 9454 9559 9682  spin_lock 9 2111/tcp_ipv4.c c0226736119/softirq.c
>    2 9540 9551 9563  spin_lock 3 2111/tcp_ipv4.c c0226736119/softirq.c
> 3895 7708 9532 14296 spin_lock 1 2111/tcp_ipv4.c c0226736119/softirq.c
>    1 9513 9513 9513  spin_lock 1 2111/tcp_ipv4.c c02267362152/tcp_ipv4.c
>  363 3594 6166 9512  spin_lock 0 2111/tcp_ipv4.c c02267362152/tcp_ipv4.c
> ----[ SNIP ]----
> 
> that 3895 number for '2111/tcp_ipv4.c c0226736119/softirq.c'
> keeps adding up, how should I translate that? big network
> latency, is that what it means? if so, any idea on how
> can I fix that??

the n column is the number of times the lock has been held.  the lock is
probably held numerous times in a given second, so you see large n
values.

note that all those rows you showed could be in one row, but the
top-latencies tool keeps them separate since they have a different mask.

anyhow, the max recorded latency is 9.5ms which is not too bad.  I'm not
looking at the code, but I would imagine its some TCP work done in a
BH.  I wouldn't worry too much.

	Robert Love