All of lore.kernel.org
 help / color / mirror / Atom feed
From: Timothy Miller <miller@techsource.com>
To: "J.A. Magallon" <jamagallon@able.es>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: naive questions about thrashing
Date: Thu, 01 May 2003 11:52:53 -0400	[thread overview]
Message-ID: <3EB142D5.60506@techsource.com> (raw)
In-Reply-To: 20030430230701.GA7256@werewolf.able.es



J.A. Magallon wrote:
> On 04.30, Timothy Miller wrote:
> 
>>I am running kernel version 2.4.18-26.7.x under Red Hat 7.2.
>>
>>I wrote a CPU-intensive program which attempts to use over 700 megs of 
>>RAM on a 512-meg box, therefore it thrashes.
>>
>>One thing I noticed was that 'top' reported that the kernel ("system") 
>>was using 68% of the CPU.  (The offending process was getting about 9%.) 
>>  How much CPU involvement is there in sending I/O requests to the drive 
>>and waiting on an interrupt?  Maybe I don't understand what's going on, 
>>but I would expect the CPU involvement in disk I/O to be practically 
>>NIL, unless it's trying to be really smart about it.  Is it?  Or maybe 
>>the kernel isn't using DMA... this is a Dell Precision 340.  I'm not 
>>sure what drive is in it, but I would be surprised if it weren't using DMA.
>>
> 
> 
> As I understand it, it is telling you that your programs spends 68% of
> its time is kernel space, ie, waiting your pages to come from disk. It
> does not mean that the CPU is doing anything, but it is locked by the
> kernel.

What would the kernel be locked while waiting on disk I/O?  Shouldn't it 
be running another process?  It's not DOING anything.  The whole idea 
behind a multitasking OS is to overlap the I/O of one process with the 
CPU usage of another whenever possible.  Swapping is an I/O operation.

And for that matter, if every runnable process has pages swapped out so 
that they cannot run, then the CPU should be IDLE.

Am I wrong?

> 
> If you can't afford to buy more memory, recode the thing. So much thrashing
> looks like you access your data very randomly. Try to process the data
> in a more sequential way, so you just fault after processing a big bunch
> of data. With 700Mb of data and a 512Mb box, at least half of your data
> fit in memory, so under an ideal sequential access you just would page
> 300Mb one time...
> 

The process got that large because of a bug in my program.  But a 
side-effect of that was kernel behavior that didn't make sense to me.  I 
decided to ask about it.


      reply	other threads:[~2003-05-01 15:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-30 18:02 naive questions about thrashing Timothy Miller
2003-04-30 23:07 ` J.A. Magallon
2003-05-01 15:52   ` Timothy Miller [this message]

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=3EB142D5.60506@techsource.com \
    --to=miller@techsource.com \
    --cc=jamagallon@able.es \
    --cc=linux-kernel@vger.kernel.org \
    /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.