public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marcelo <marcelo.tosatti@cyclades.com>
To: Christopher Friesen <cfriesen@nortel.com>
Cc: Marcelo <marcelo.tosatti@cyclades.com>,
	linux-kernel@vger.kernel.org, paulmck@us.ibm.com,
	"Theodore Ts'o" <tytso@mit.edu>,
	dipankar@in.ibm.com, viro@ftp.linux.org.uk
Subject: Re: dentry_cache using up all my zone normal memory
Date: Sun, 2 Oct 2005 16:55:30 -0300	[thread overview]
Message-ID: <20051002195530.GA9865@xeon.cnet> (raw)
In-Reply-To: <433F7877.1060707@nortel.com>

On Sun, Oct 02, 2005 at 12:04:39AM -0600, Christopher Friesen wrote:
> Marcelo wrote:
> 
> >How can this be reproduced? (point to a URL if you already explained
> >that in detail).
> 
> I mentioned this earlier in the thread.  I'm running 2.6.14-rc4 on a 
> pentium-M based atca blade with a bit over 3GB of memory.  When I run 
> the "rename14" test from LTP with /tmp mounted on tmpfs, the system runs 
> out of zone normal memory and the OOM killer starts killing processes.
> 
> If I have /tmp mounted nfs, the problem doesn't occur.  If I use the 
> boot args to limit the memory to 896MB the problem doesn't occur.  If I 
> run the testcase on a dual Xeon with multiple gigs of memory, the 
> problem doesn't occur.
> 
> >Someone else on the thread said you had zillions of file descriptors
> >open?
> 
> This does not appear to be the case.  The testcase has two threads.
> 
> thread 1 loops doing the following:
> fd = creat("./rename14", 0666);
> unlink("./rename14");
> close(fd);
> 
> thread 2 loops doing:
> rename("./rename14", "./rename14xyz");
> 
> >Need to figure out they can't be freed. The kernel is surely trying it
> >(also a problem if it is not trying). How does the "slabs_scanned" field
> >of /proc/vmstats looks like?
> 
> That's something I haven't checked...will have to get back to you.
> 
> >Bharata maintains a patch to record additional statistics, haven't 
> >you tried it already?
> 
> Already tried.  You should be able to find results earlier in this thread.

Sorry, the problem is queueing of large amounts of RCU callbacks in a
short period of time, as already discussed.

Since ksoftirq is running (as can be seen from the dumps you sent), I
_guess_ that the grace period has happened already, and ksoftirq is
attempting to execute the RCU callbacks.

An important fact that causes the direct reclaim throttling to fail is
the complete lack of pagecache pages on both DMA and normal zones (zero
on both).

Can you try this hack (might need to include linux/interrupt.h and
linux/rcupdate.h)

--- mm/vmscan.c.orig    2005-10-02 16:10:05.000000000 -0300
+++ mm/vmscan.c 2005-10-02 16:27:25.000000000 -0300
@@ -953,6 +953,12 @@ int try_to_free_pages(struct zone **zone
                sc.swap_cluster_max = SWAP_CLUSTER_MAX;
                shrink_caches(zones, &sc);
                shrink_slab(sc.nr_scanned, gfp_mask, lru_pages);
+               /* throttle RCU deletion of SLAB objects if in trouble */
+               if (priority < DEF_PRIORITY/2) {
+                       synchronize_rcu();
+                       if (local_softirq_pending())
+                               do_softirq();
+               }
                if (reclaim_state) {
                        sc.nr_reclaimed += reclaim_state->reclaimed_slab;
                        reclaim_state->reclaimed_slab = 0;




      reply	other threads:[~2005-10-02 19:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-21 16:26 dentry_cache using up all my zone normal memory Christopher Friesen
2005-09-21 16:53 ` Christopher Friesen
2005-09-21 19:46   ` dentry_cache using up all my zone normal memory -- also seen on 2.6.14-rc2 Christopher Friesen
2005-09-21 20:07     ` Sonny Rao
2005-09-21 20:27       ` Christopher Friesen
2005-09-21 20:49       ` Christopher Friesen
2005-09-21 20:59       ` Christopher Friesen
2005-09-21 20:58         ` Sonny Rao
2005-09-21 21:00         ` Dipankar Sarma
2005-09-21 21:14           ` Al Viro
2005-09-21 21:14           ` Trond Myklebust
2005-09-21 21:25             ` Christopher Friesen
2005-09-21 21:29               ` Christopher Friesen
2005-09-21 21:25           ` Christopher Friesen
2005-09-21 22:03             ` Roland Dreier
2005-09-22  3:11               ` Al Viro
2005-09-22  3:54                 ` Christopher Friesen
2005-09-22  4:17                   ` Al Viro
2005-09-22 14:47                     ` Christopher Friesen
2005-09-22 15:16                     ` Christopher Friesen
2005-09-22 18:12                       ` dentry_cache using up all my zone normal memory -- new data point Christopher Friesen
2005-09-22 18:27                       ` dentry_cache using up all my zone normal memory -- also seen on 2.6.14-rc2 Dipankar Sarma
2005-09-22 19:03                         ` Christopher Friesen
2005-09-22 19:18                           ` Dipankar Sarma
2005-09-22 21:37                             ` Christopher Friesen
2005-09-22 21:44                               ` Sonny Rao
2005-09-22 21:55                                 ` Christopher Friesen
2005-09-22 22:04                                   ` Randy.Dunlap
2005-09-26  4:43                                     ` [PATCH/RFC] sysrq: updating console_loglevel Randy.Dunlap
2005-09-22 22:05                             ` dentry_cache using up all my zone normal memory -- also seen on 2.6.14-rc2 Christopher Friesen
2005-10-04 19:43                       ` Dipankar Sarma
2005-10-04 20:02                         ` Christopher Friesen
2005-10-05  4:00                           ` Dipankar Sarma
2005-09-30 22:03 ` dentry_cache using up all my zone normal memory Christopher Friesen
2005-10-01 23:22   ` Marcelo
2005-10-02  6:04     ` Christopher Friesen
2005-10-02 19:55       ` Marcelo [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=20051002195530.GA9865@xeon.cnet \
    --to=marcelo.tosatti@cyclades.com \
    --cc=cfriesen@nortel.com \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@us.ibm.com \
    --cc=tytso@mit.edu \
    --cc=viro@ftp.linux.org.uk \
    /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