linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Benjamin C.R. LaHaise" <blah@kvack.org>
To: Pavel Machek <pavel@elf.ucw.cz>
Cc: Rik van Riel <H.H.vanRiel@fys.ruu.nl>,
	"Michael L. Galbraith" <mikeg@weiden.de>,
	linux-mm <linux-mm@kvack.org>,
	linux-kernel <linux-kernel@vger.rutgers.edu>
Subject: Re: [PATCH] kswapd fix & logic improvement
Date: Fri, 6 Mar 1998 04:06:22 -0500 (U\x01)	[thread overview]
Message-ID: <Pine.LNX.3.95.980306035709.11210A-100000@as200.spellcast.com> (raw)
In-Reply-To: <19980304093300.08111@Elf.mj.gts.cz>

Hello!

On Wed, 4 Mar 1998, Pavel Machek wrote:
...
> > Not only that, but the network activity X induces puts additional stress
> > on an already low-memory system by allocating lots of unswappable memory.
> > When might we see Pavel's patches to the networking stack meant to get
> > swapping over TCP working, but I think they'll really help stability on 
> > systems with low-memory and busy networks, get integrated?
> 
> Sorry? My patches are usable only if you are trying to swap over
> network. They will not help on low-memory systems, unless that systems
> also lack hard-drives. It is usually much better to swap onto local
> drive than over network.

If they're setup the way I think they are, you're mistaken. ;-)  I'm
thinking of the pathelogical case where the system is thrown into a state
where atomic memory consumption is occurring faster than the system can
free up memory.  This could occur on a system with, say 100Mbps ethernet
and a low-end IDE drive (~5-7MBps peak) if we're using TCP with large
windows and have a *large* number of sockets open and receiving data. 
Incoming packets could consume up to 10MB of GFP_ATOMIC memory per second
- ouch!  With your patch, once we hit a danger zone, the system starts
dropping network packets, right?  That way there will still be enough
memory for allocating buffer heads and such to swap out as nescessary... 

		-ben

  reply	other threads:[~1998-03-06  9:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-03-03  0:35 Rik van Riel
1998-03-03  7:16 ` Michael L. Galbraith
1998-03-03  7:39   ` Rik van Riel
1998-03-03 16:10     ` Michael L. Galbraith
1998-03-03 17:16       ` Rik van Riel
1998-03-03 19:17         ` Benjamin C.R. LaHaise
1998-03-04  8:33           ` Pavel Machek
1998-03-06  9:06             ` Benjamin C.R. LaHaise [this message]
1998-03-06 14:40               ` Pavel Machek
     [not found] <199803031135.MAA19461@max.fys.ruu.nl>
1998-03-03 13:10 ` Rik van Riel

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.3.95.980306035709.11210A-100000@as200.spellcast.com \
    --to=blah@kvack.org \
    --cc=H.H.vanRiel@fys.ruu.nl \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=mikeg@weiden.de \
    --cc=pavel@elf.ucw.cz \
    /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