All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.