From: Christoph Lameter <clameter@sgi.com>
To: Ravikiran G Thirumalai <kiran@scalex86.org>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andi Kleen <ak@suse.de>, Andrew Morton <akpm@osdl.org>,
"Shai Fultheim (Shai@scalex86.org)" <shai@scalex86.org>,
pravin b shelar <pravin.shelar@calsoftinc.com>
Subject: Re: High lock spin time for zone->lru_lock under extreme conditions
Date: Fri, 12 Jan 2007 11:46:22 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0701121137430.2306@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20070112160104.GA5766@localhost.localdomain>
On Fri, 12 Jan 2007, Ravikiran G Thirumalai wrote:
> The test was simple, we have 16 processes, each allocating 3.5G of memory
> and and touching each and every page and returning. Each of the process is
> bound to a node (socket), with the local node being the preferred node for
> allocation (numactl --cpubind=$node ./numa-membomb --preferred=$node). Each
> socket has 4G of physical memory and there are two cores on each socket. On
> start of the test, the machine becomes unresponsive after sometime and
> prints out softlockup and OOM messages. We then found out the cause
> for softlockups being the excessive spin times on zone_lru lock. The fact
> that spin_lock_irq disables interrupts while spinning made matters very bad.
> We instrumented the spin_lock_irq code and found that the spin time on the
> lru locks was in the order of a few seconds (tens of seconds at times) and
> the hold time was comparatively lesser.
So the issue is two processes contenting on the zone lock for one node?
You are overallocating the 4G node with two processes attempting to
allocate 7.5GB? So we go off node for 3.5G of the allocation?
Does the system scale the right way if you stay within the bounds of node
memory? I.e. allocate 1.5GB from each process?
Have you tried increasing the size of the per cpu caches in
/proc/sys/vm/percpu_pagelist_fraction?
> While the softlockups and the like went away by enabling interrupts during
> spinning, as mentioned in http://lkml.org/lkml/2007/1/3/29 ,
> Andi thought maybe this is exposing a problem with zone->lru_locks and
> hence warrants a discussion on lkml, hence this post. Are there any
> plans/patches/ideas to address the spin time under such extreme conditions?
Could this be a hardware problem? Some issue with atomic ops in the
Sun hardware?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-01-12 19:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 16:01 Ravikiran G Thirumalai
2007-01-12 17:03 ` Peter Zijlstra
2007-01-12 19:46 ` Christoph Lameter [this message]
2007-01-12 21:25 ` Andrew Morton
2007-01-12 21:40 ` Ravikiran G Thirumalai
2007-01-12 21:45 ` Christoph Lameter
2007-01-13 1:00 ` Ravikiran G Thirumalai
2007-01-13 1:11 ` Andrew Morton
2007-01-13 7:42 ` Ravikiran G Thirumalai
2007-01-13 4:39 ` Nick Piggin
2007-01-13 7:36 ` Ravikiran G Thirumalai
2007-01-13 7:53 ` Nick Piggin
2007-01-13 8:00 ` Andrew Morton
2007-01-13 19:53 ` Ravikiran G Thirumalai
2007-01-13 21:20 ` Andrew Morton
2007-01-16 2:56 ` Ravikiran G Thirumalai
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=Pine.LNX.4.64.0701121137430.2306@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--cc=kiran@scalex86.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pravin.shelar@calsoftinc.com \
--cc=shai@scalex86.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox