linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	marcelo@kvack.org, daniel.spang@gmail.com, riel@redhat.com,
	akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk,
	linux-fsdevel@vger.kernel.org, pavel@ucw.cz, a1426z@gawab.com,
	jonathan@jonmasters.org, zlynx@acm.org
Subject: Re: [PATCH 0/8][for -mm] mem_notify v6
Date: Tue, 19 Feb 2008 09:00:08 -0600	[thread overview]
Message-ID: <20080219090008.bb6cbe2f.pj@sgi.com> (raw)
In-Reply-To: <20080219145108.7E96.KOSAKI.MOTOHIRO@jp.fujitsu.com>

Kosaki-san wrote:
> Thank you for wonderful interestings comment.

You're most welcome.  The pleasure is all mine.

> you think kill the process just after swap, right?
> but unfortunately, almost user hope receive notification before swap ;-)
> because avoid swap.

There is not much my customers HPC jobs can do with notification before
swap.  Their jobs either have the main memory they need to perform the
requested calculations with the desired performance, or their job is
useless and should be killed.  Unlike the applications you describe,
my customers jobs have no way, once running, to adapt to less memory.
They can only adapt to less memory by being restarted with a different
set of resource requests to the job scheduler (the application that
manages job requests, assigns them CPU, memory and other resources,
and monitors, starts, stops and pauses jobs.)

The primary difficulty my HPC customers have is killing such jobs fast
enough, before a bad job (one that attempts to use more memory than it
signed up for) can harm the performance of other users and the rest of
the system.

I don't mind if a pages are slowly or occassionally written to swap;
but as soon as the task wants to reclaim big chunks of memory by
writing thousands of pages at once to swap, it must die, and die
before it can queue more than a handful of those pages to the swapper.

> but embedded people strongly dislike bloat code size.
> I think they never turn on CPUSET.
> 
> I hope mem_notify works fine without CPUSET.

Yes - understood and agreed - as I guessed, cpusets are not configured
in embedded systems.

> Please don't think I reject your idea.
> your proposal is large different of past our discussion

Yes - I agree that my ideas were quite different.  Please don't
hesitate to reject every one of them, like a Samurai slicing through
air with his favorite sword <grin>.

> Disagreed. that [my direct reclaim hook at mapping->a_ops->writepage()]
> is too late.

For your work, yes that hook is too late.  Agreed.

Depending on what we're trying to do:
 1) warn applications of swap coming soon (your case),
 2) show how close we are to swapping,
 3) show how much swap has happened already,
 4) kill instantly if try to swap (my hpc case),
 5) measure file i/o caused by memory pressure, or
 6) perhaps other goals,
we will need to hook different places in the kernel.

It may well be that your hooks for embedded are simply in different
places than my hooks for HPC.  If so, that's fine.

I look forward to your further thoughts.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

--
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>

  reply	other threads:[~2008-02-19 15:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-09 15:19 KOSAKI Motohiro
2008-02-09 16:02 ` Jon Masters
2008-02-09 16:33   ` KOSAKI Motohiro
2008-02-09 16:43     ` Rik van Riel
2008-02-09 16:49       ` KOSAKI Motohiro
2008-02-11 15:36 ` [PATCH 0/8][for -mm] mem_notify v6, " Jonathan Corbet
2008-02-11 15:46   ` KOSAKI Motohiro
2008-02-17 14:49 ` Paul Jackson
2008-02-19  7:36   ` KOSAKI Motohiro
2008-02-19 15:00     ` Paul Jackson [this message]
2008-02-19 19:02       ` Rik van Riel
2008-02-19 20:18         ` Paul Jackson
2008-02-19 20:43           ` Paul Jackson
2008-02-19 22:28       ` Pavel Machek
2008-02-20  1:54         ` Paul Jackson
2008-02-20  2:07         ` Rik van Riel
2008-02-20  2:48           ` KOSAKI Motohiro
2008-02-20  4:57             ` Paul Jackson
2008-02-20  5:21               ` KOSAKI Motohiro
2008-02-20  4:36           ` Paul Jackson
2008-04-01 23:35 ` Tom May
2008-04-02  7:31   ` KOSAKI Motohiro
2008-04-02 17:45     ` Tom May
2008-04-15  0:16     ` Tom May
2008-04-16  2:30       ` KOSAKI Motohiro
2008-04-17  9:30       ` KOSAKI Motohiro
2008-04-17 19:23         ` Tom May
2008-04-18 10:07           ` KOSAKI Motohiro
2008-04-21 20:32             ` Tom May
2008-04-23  8:27           ` Daniel Spång
2008-05-01  2:07             ` Tom May
2008-05-01 15:06               ` KOSAKI Motohiro
2008-05-02 22:21                 ` Tom May
2008-05-03 12:26                   ` KOSAKI Motohiro
2008-05-06  5:22                     ` Tom May

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=20080219090008.bb6cbe2f.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=a1426z@gawab.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=daniel.spang@gmail.com \
    --cc=jonathan@jonmasters.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=marcelo@kvack.org \
    --cc=pavel@ucw.cz \
    --cc=riel@redhat.com \
    --cc=zlynx@acm.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