mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Mohr <andi@lisas.de>
To: venkata koppula <vmrkoppula@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Copying large files eats all of the RAM
Date: Fri, 29 Nov 2013 22:56:16 +0100	[thread overview]
Message-ID: <20131129215616.GA32242@rhlx01.hs-esslingen.de> (raw)
In-Reply-To: <CAKK=TUJ=ebu3+hBQmm+5=uooCFo9y3oAS_JfSn_KOtfxCLBvQQ@mail.gmail.com>

Hi,

> My laptop has 4GB of ram, before I issue the command around 1.5GB of
> memory
> is used, when I issue the cp command around 3.7GB of memory is used.
> And the cp command takes a lot of time to copy.
> 
> I am not able to launch other applications(take a lot of time) and
> even compiz freezes frequently. my laptop has Ubuntu installed on it.
> 
> Is this the problem with only my system or it is a common problem with
> Linux?.
> 
> Is there any way to stop any copy command to use all of my memory.

The purpose of a good operating system is *exactly* to optimize the
*all* RAM is used, *all* the time optimum to the highest degree.
Or would you want to have your power supply used to power useless
memory that's sitting idle?

It's probably a good idea to read up on the many sites which explain
important OS caching mechanisms.

That said, there may of course be situations where too much
competition/contention for resources occurs, or where calculation of the
kept-free-for-reuse memory amount is sub-optimal, leaving overly scarce
amounts of memory available for immediate use.
But that should be a matter of optimizing core kernel algorithms
even more than they already are.

And it's also known that for certain situations (e.g. trying to push very large
amounts of data over a lowly USB 1.1 USB stick connection),
Linux does (or did?) tend to have issues with that cached data piling up
in somewhat negative ways prior to getting flushed over the connection,
thereby causing system performance to degrade (I'm not in the know of
how much that still applies to very new Linux kernel versions).

But in your case that might simply be a problem of your particular
hardware (IRQ issues, improperly implemented drivers, ...).
Some benchmarking activities might be able to provide more details
(e.g. hdparm -tT, bonnie++ results, memory performance tests, etc.).

cat /proc/slabinfo
ought to provide an initial overview of which cache elements
manage to keep the largest memory areas in service.

HTH,

Andreas Mohr

  reply	other threads:[~2013-11-29 21:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-28 14:01 venkata koppula
2013-11-29 21:56 ` Andreas Mohr [this message]
2013-11-29 23:42   ` Austin S Hemmelgarn
2013-11-30  6:29     ` venkata koppula
2013-11-30 13:04       ` Henrique de Moraes Holschuh
2013-12-02 21:30       ` Andreas Mohr

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=20131129215616.GA32242@rhlx01.hs-esslingen.de \
    --to=andi@lisas.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vmrkoppula@gmail.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

all inboxes | Powered by JetHome®