public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Ken Brownfield <brownfld@irridia.com>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@transmeta.com>,
	Marcelo Tosatti <marcelo@conectiva.com.br>,
	Daniel Phillips <phillips@bonn-fries.net>
Subject: Re: 2.4.>=13 VM/kswapd/shmem/Oracle issue (was Re: Google's mm problems)
Date: Thu, 15 Nov 2001 18:40:36 +0100	[thread overview]
Message-ID: <20011115184036.D1381@athlon.random> (raw)
In-Reply-To: <E15yhyY-0000Yb-00@starship.berlin> <20011109033851.A15099@asooo.flowerfire.com>
In-Reply-To: <20011109033851.A15099@asooo.flowerfire.com>; from brownfld@irridia.com on Fri, Nov 09, 2001 at 03:38:51AM -0600

On Fri, Nov 09, 2001 at 03:38:51AM -0600, Ken Brownfield wrote:
> We're seeing an easily reproducible problem that I believe to be along
> the same lines as what Google is seeing.  I'm not sure if Oracle's SGA

FYI: yes, that's the same problem. After some debugging I found the
exact reason of the bug, and as Daniel claimed a few weeks ago it is
really a VM problem, not an mlock problem. And it's one thing that I
didn't noticed while rewriting the VM, so it is reproducible on all 2.4
kernels out there, no matter what VM is in them. The kswapd infinite
loop that can trigger with the -ac VM when all the ZONE_DMA is
unfreeable (now fixed in mainline with classzone) have nothing to do
with this google problem, kswapd is right here to spend cpu time, the
bug is not kswapd activation.

I just sent Ben (at Google) a patch that fixes the problem completly for
me and for him and I'll try to release the real fix in the next days.
(so far it's a dirty workaround, that is just usable fine in their and
my memory configuration but it's not general purpose yet, but it's been
more than enough to proof my theory so far and I've in mind how to fix
it properly, tomorrow I hope I will implement it).

Andrea

  parent reply	other threads:[~2001-11-15 17:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-30 23:07 Google's mm problems Daniel Phillips
2001-11-01 20:00 ` Google's mm problems with 2.4.13 and 4G of memory Sven Heinicke
2001-11-02 22:24   ` Daniel Phillips
2001-11-03 20:56 ` Google's mm problems Christian Ehrhardt
2001-11-04  3:29   ` Daniel Phillips
2001-11-05 16:10     ` Sven Heinicke
2001-11-09  9:38 ` 2.4.>=13 VM/kswapd/shmem/Oracle issue (was Re: Google's mm problems) Ken Brownfield
2001-11-09 22:39   ` vda
2001-11-15 17:40   ` Andrea Arcangeli [this message]
2001-11-15 17:48     ` Arjan van de Ven
2001-11-17 15:54       ` Andrea Arcangeli
2001-11-18  6:17         ` Mike Galbraith
2001-11-18  6:27           ` Andrea Arcangeli
2001-11-18  7:14             ` Mike Galbraith
2001-11-15 20:07     ` Ken Brownfield

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=20011115184036.D1381@athlon.random \
    --to=andrea@suse.de \
    --cc=brownfld@irridia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=phillips@bonn-fries.net \
    --cc=torvalds@transmeta.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