From: Harry Edmon <harry@atmos.washington.edu>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SUNRPC problem with 2.6.26 and beyond - try again with response in correct place.
Date: Wed, 22 Oct 2008 15:55:43 -0700 [thread overview]
Message-ID: <48FFAF6F.3040406@atmos.washington.edu> (raw)
In-Reply-To: <1224715874.7525.18.camel@localhost>
Trond Myklebust wrote:
> On Wed, 2008-10-22 at 08:35 -0700, Harry Edmon wrote:
>
>> I have a dual quad-core Xeon system running software
>> (http://www.unidata.ucar.edu/software/ldm) that relays and processes
>> weather data through RPC calls, keeping a queue of data in a memory
>> mapped file. Up until 2.6.26 the system has run just fine (for example
>> 2.6.25.17). But starting with 2.6.26 through 2.6.27.2 the system runs
>> into a problem after approximately 24 hours. The symptom is that the
>> processing slows down to a crawl. Using "top" I can see that the System
>> time is up over 90%, with almost no User and Wait time. If I stop and
>> restart the software, most of the time it gets better - but sometimes it
>> takes a reboot to fix the problem. I have an identical system that does
>> just processing and ingesting data from remote systems, and it does not
>> have this problem. I have tried a number of different kernel
>> configurations, but they all show the same problem.
>>
>> I suspect a problem with SUNRPC. I notice that there were a large
>> number of SUNRPC patches in 2.6.26. I am looking for suggestions on how
>> to pin down which patches are causing the problem. Are there ways to
>> figure where in the kernel the time is being spent? I am will to work
>> on isolating the problem, but I need some suggestions on the best way to
>> do it given the large number of SUNRPC patches in 2.6.26 and the fact
>> that each experiment takes a day.
>>
>
> The kernel sunrpc interface is not exported to user land: the glibc code
> uses its own, entirely separate implementation of sunrpc.
>
> I cannot therefore see, how your application's RPC calls can be affected
> by kernel sunrpc changes.
>
> Cheers
> Trond
>
>
Then how do you explain the the large system time used with 2.6.26 and
beyond? Is it some other patch I should be looking at?
--
Dr. Harry Edmon E-MAIL: harry@atmos.washington.edu
206-543-0547 harry@washington.edu
Dept of Atmospheric Sciences FAX: 206-543-0308
University of Washington, Box 351640, Seattle, WA 98195-1640
next prev parent reply other threads:[~2008-10-22 22:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-22 15:35 SUNRPC problem with 2.6.26 and beyond Harry Edmon
2008-10-22 22:51 ` Trond Myklebust
2008-10-22 22:54 ` Harry Edmon
2008-10-22 22:55 ` Harry Edmon [this message]
2008-10-22 23:37 ` SUNRPC problem with 2.6.26 and beyond - try again with response in correct place Trond Myklebust
2008-10-23 1:27 ` Harry Edmon
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=48FFAF6F.3040406@atmos.washington.edu \
--to=harry@atmos.washington.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.