From: Brian Tinsley <btinsley@emageon.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
Date: Thu, 09 Jan 2003 22:50:03 -0600 [thread overview]
Message-ID: <3E1E50FB.4000301@emageon.com> (raw)
In-Reply-To: 20030110041918.GK23814@holomorphy.com
>
>
>We're straying from the subject here.
>
Sorry
>Please describe your machine,
>in terms of how many cpus it has and how much highmem it has, and
>your workload, so I can better determine the issue. Perhaps we can
>cooperatively devise something that works well for you.
>
IBM x360
Pentium 4 Xeon MP processors
2 processor system has 4GB RAM
4 processor system has 8GB RAM
1 IBM ServeRAID controller
2 Intel PRO/1000MT NICs
2 QLogic 2340 Fibre Channel HBAs
>Or perhaps the kernel version is not up-to-date. Please also provide
>the precise kernel version (and included patches). And workload too.
>
The kernel version is stock 2.4.20 with Chris Mason's data logging and
journal relocation patches for ReiserFS (neither of which are actually
in use for any mounted filesystems). It is compiled for 64GB highmem
support. And just to refresh, I have seen this exact behavior on stock
2.4.19 and stock 2.4.17 (no patches on either of these) also compiled
with 64GB highmem support.
Workload:
When the live-lock occurs, the system is performing intensive network
I/O and intensive disk reads from the fibre channel storage (i.e., the
backup program is reading files from disk and transferring them to the
backup server). I posted a snapshot of sar data collection earlier today
showing selected stats leading up to and just after the live-lock occurs
(which is noted by a ~2 minute gap in sar logging). After the live-lock
is released, the only thing that stands out is an unusual increase in
runtime for kswapd (as reported by ps).
The various Java programs mentioned in prior postings are *mostly* idle
at this point in time as it is after hours for our clients.
next prev parent reply other threads:[~2003-01-10 4:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-10 3:17 2.4.20, .text.lock.swap cpu usage? (ibm x440) Brian Tinsley
2003-01-10 3:29 ` William Lee Irwin III
2003-01-10 3:42 ` Brian Tinsley
2003-01-10 3:54 ` William Lee Irwin III
2003-01-10 4:08 ` Brian Tinsley
2003-01-10 4:19 ` William Lee Irwin III
2003-01-10 4:50 ` Brian Tinsley [this message]
2003-01-10 5:17 ` Martin J. Bligh
2003-01-10 5:24 ` William Lee Irwin III
2003-01-10 5:45 ` Brian Tinsley
-- strict thread matches above, loose matches on Subject: below --
2003-01-06 23:35 Chris Wood
2003-01-06 23:50 ` William Lee Irwin III
2003-01-06 23:52 ` Andrew Morton
2003-01-09 17:17 ` Chris Wood
2003-01-09 20:18 ` Andrew Morton
2003-01-10 0:25 ` William Lee Irwin III
2003-01-10 0:44 ` Brian Tinsley
2003-01-10 0:55 ` William Lee Irwin III
2003-01-10 20:42 ` Chris Wood
2003-01-09 2:20 ` James Cleverdon
2003-01-09 2:57 ` William Lee Irwin III
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E1E50FB.4000301@emageon.com \
--to=btinsley@emageon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=wli@holomorphy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox