linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: "He, Roger" <Hongbo.He@amd.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] mm/swap: add function get_total_swap_pages to expose total_swap_pages
Date: Tue, 30 Jan 2018 11:18:23 +0100	[thread overview]
Message-ID: <20180130101823.GX21609@dhcp22.suse.cz> (raw)
In-Reply-To: <9060281e-62dd-8775-2903-339ff836b436@amd.com>

On Tue 30-01-18 10:00:07, Christian Konig wrote:
> Am 30.01.2018 um 08:55 schrieb Michal Hocko:
> > On Tue 30-01-18 02:56:51, He, Roger wrote:
> > > Hi Michal:
> > > 
> > > We need a API to tell TTM module the system totally has how many swap
> > > cache.  Then TTM module can use it to restrict how many the swap cache
> > > it can use to prevent triggering OOM.  For Now we set the threshold of
> > > swap size TTM used as 1/2 * total size and leave the rest for others
> > > use.
> > Why do you so much memory? Are you going to use TB of memory on large
> > systems? What about memory hotplug when the memory is added/released?
> 
> For graphics and compute applications on GPUs it isn't unusual to use large
> amounts of system memory.
> 
> Our standard policy in TTM is to allow 50% of system memory to be pinned for
> use with GPUs (the hardware can't do page faults).
> 
> When that limit is exceeded (or the shrinker callbacks tell us to make room)
> we wait for any GPU work to finish and copy buffer content into a shmem
> file.
> 
> This copy into a shmem file can easily trigger the OOM killer if there isn't
> any swap space left and that is something we want to avoid.
> 
> So what we want to do is to apply this 50% rule to swap space as well and
> deny allocation of buffer objects when it is exceeded.

How does that help when the rest of the system might eat swap?

> > > But get_nr_swap_pages is the only API we can accessed from other
> > > module now.  It can't cover the case of the dynamic swap size
> > > increment.  I mean: user can use "swapon" to enable new swap file or
> > > swap disk dynamically or "swapoff" to disable swap space.
> > Exactly. Your scaling configuration based on get_nr_swap_pages or the
> > available memory simply sounds wrong.
> 
> Why? That is pretty much exactly what we are doing with buffer objects and
> system memory for years.

Could you be more specific? What kind of buffer objects you have in
mind?

-- 
Michal Hocko
SUSE Labs

--
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:[~2018-01-30 10:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29  8:29 Roger He
2018-01-29 16:31 ` Michal Hocko
2018-01-30  2:56   ` He, Roger
2018-01-30  5:13     ` He, Roger
2018-01-30  7:55     ` Michal Hocko
2018-01-30  9:00       ` Christian König
2018-01-30 10:18         ` Michal Hocko [this message]
2018-01-30 10:32           ` Christian König
2018-01-30 12:28             ` Michal Hocko
2018-01-30 12:52               ` Christian König
2018-01-31  5:52               ` He, Roger
2018-02-01  6:13               ` He, Roger
2018-02-01  8:15                 ` Michal Hocko
2018-01-31  7:15 ` Chunming Zhou
2018-01-31  8:08   ` He, Roger
2018-01-31  8:12     ` Christian König
2018-01-31  8:52       ` Chunming Zhou
2018-02-01  5:48       ` He, Roger
2018-02-01  8:03         ` He, Roger
2018-02-02  6:57         ` He, Roger
2018-02-02  7:46           ` Christian König
2018-02-02  7:54             ` He, Roger

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=20180130101823.GX21609@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=Hongbo.He@amd.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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