2001-10-16 17:52:01

by elko

[permalink] [raw]
Subject: looking for a preempt-patch for 2.4.10-ac12


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



2001-10-16 18:44:44

by Jose Luis Domingo Lopez

[permalink] [raw]
Subject: Re: looking for a preempt-patch for 2.4.10-ac12

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

2001-10-17 19:46:57

by elko

[permalink] [raw]
Subject: Re: looking for a preempt-patch for 2.4.10-ac12

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


2001-10-17 19:53:47

by Robert Love

[permalink] [raw]
Subject: Re: looking for a preempt-patch for 2.4.10-ac12

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