public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: pre6 VM issues
Date: Tue, 9 Oct 2001 17:39:37 +0200	[thread overview]
Message-ID: <20011009173937.M15943@athlon.random> (raw)
In-Reply-To: <20011009165002.H15943@athlon.random> <Pine.LNX.4.21.0110091129260.5604-100000@freak.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0110091129260.5604-100000@freak.distro.conectiva>; from marcelo@conectiva.com.br on Tue, Oct 09, 2001 at 11:34:47AM -0200

On Tue, Oct 09, 2001 at 11:34:47AM -0200, Marcelo Tosatti wrote:
> The problem may well be in the memory balancing Andrea, but I'm not trying
> to hide it with the infinite loop.

I assumed fixing the oom faliures with highmem was the main reason of
the infinite loop.

> The infinite loop is just a guarantee that we'll have a reliable way of
> throttling the allocators which can block. Not doing the infinite loop is

Throttling have nothing to do with the infinite loop.

> just way too fragile IMO and it is _prone_ to fail in intensive
> loads. 

It is too fragile if the vm is doing the wrong actions and so we must
loop over and over again before it finally does the right thing.

If allocation fails that's a nice feedback that tell us "the memory
balancing is at least inefficient in doing the right thing, looping
would only waste more cache and more time for the allocation".

Think a list where pages can be only freeable or unfreeable.  Now scan
_all_ the pages and free all the freeable ones. Finished. If it failed
and it couldn't free anything it means there was nothing to free so
we're oom. How can that be "fragile"?

In real life it isn't as simple as that, there's some "race" effect
caming from the schedules in between, there are multiple lists, there's
swapout etc... so it's a little more complex than just "freeable" and
"unfreeable" and a single list, but it can be done, 2.2 does that too,
if we loop over and over again and we do no progress in the right
direction I prefer to know about that via an allocation faliure rather
than by just getting sucking performance. Also an allocation faliure is
a minor problem compared to a deadlock that the infinite loop cannot
prevent.

> If the problem is the highmem balancing, I'll love to get your fixes and
> integrate with the infinite loop logic, which is a separated (related,
> yes, but separate) thing.

The infinite loop shouldn't do anything except introducing the deadlock
after that (otherwise it means I failed :), but you're free to go in
your direction if you think it's the right one of course (like I'm free
to go in my direction since I think it's the right one).

Andrea

  reply	other threads:[~2001-10-09 15:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-10-09 12:44 pre6 VM issues Marcelo Tosatti
2001-10-09 12:48 ` Marcelo Tosatti
2001-10-09 14:17 ` BALBIR SINGH
2001-10-09 13:01   ` Marcelo Tosatti
2001-10-09 14:37     ` BALBIR SINGH
2001-10-09 13:22       ` Marcelo Tosatti
2001-10-09 14:43       ` BALBIR SINGH
2001-10-09 14:44       ` Andrea Arcangeli
2001-10-09 14:56         ` BALBIR SINGH
2001-10-09 14:31 ` Andrea Arcangeli
2001-10-09 13:13   ` Marcelo Tosatti
2001-10-09 14:42     ` Andrea Arcangeli
2001-10-09 13:23   ` Marcelo Tosatti
2001-10-09 14:53     ` Andrea Arcangeli
2001-10-09 14:50 ` Andrea Arcangeli
2001-10-09 13:34   ` Marcelo Tosatti
2001-10-09 15:39     ` Andrea Arcangeli [this message]
2001-10-09 15:08       ` Marcelo Tosatti
2001-10-09 16:49         ` Andrea Arcangeli
2001-10-09 17:07           ` Linus Torvalds

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=20011009173937.M15943@athlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --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