linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chris Edwards <chris.edwards@otago.ac.nz>
To: Johannes Weiner <hannes@cmpxchg.org>, Michal Hocko <mhocko@kernel.org>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: Paging out when free memory is low but not exhausted (and available memory remains high)
Date: Wed, 29 Jan 2020 11:36:09 +0000	[thread overview]
Message-ID: <1580297769621.48601@otago.ac.nz> (raw)
In-Reply-To: <1580195997590.47770@otago.ac.nz>

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Following the idea that it's some interaction with the X server, I further noticed that switching out of X to a text virtual console makes the page-outs stop. Going back to the X VT, the page-outs resume.

I've attached another set of vmstat logs for the following timeline:

1580290800	System is running Xorg, stress to limit memory, and dd to exercise the buffer cache, with constant page-outs
1580290810	Switch to a text virtual console - page-outs stop
1580290830	Switch back to X VT - page-outs resume

I'm vaguely suspecting something to do with the way Xorg handles old-fashioned programs that do CPU-driven bitmap-based rendering, as my desktop does typically have a lot of these (urxvt instances, xosview, the Notion window manager itself) - maybe they cause some particular pattern of memory churn in the X server, and perhaps only with certain video drivers...could Xorg perhaps wrongly madvise() the kernel about certain memory? It seems notable that having glxgears should cause the page-outs to stop.

However, even a minimal X session with a sakura or qterminal window seems to show some degree of needless page-outs with low memory and busy cache, though not as severe - however, it's difficult to avoid observer effects! There did seem to be a notable pattern of increasing swap utilisation when switching away from the X VT, and a drop in swap utilisation when switching back to X.

Should I perhaps take it up with the Xorg people instead?
--
Chris

[-- Attachment #2: vmstat_5.5.0-rc6_unpatched_cedwards_2020-01-29.tar.gz --]
[-- Type: application/gzip, Size: 12798 bytes --]

  reply	other threads:[~2020-01-29 11:36 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-22  0:40 Chris Edwards
2020-01-23 12:31 ` Michal Hocko
2020-01-24  5:43   ` Chris Edwards
2020-01-24 10:04     ` Michal Hocko
2020-01-24 10:28       ` Michal Hocko
2020-01-27 10:06       ` Johannes Weiner
2020-01-28  3:22         ` Chris Edwards
2020-01-28  4:58           ` Chris Edwards
2020-01-28  7:19             ` Chris Edwards
2020-01-29 11:36               ` Chris Edwards [this message]
2020-01-29 13:39                 ` Michal Hocko
2020-01-29 16:39                   ` Johannes Weiner
2020-02-02 22:56                     ` Chris Edwards
2020-02-10  8:50                       ` Michal Hocko

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=1580297769621.48601@otago.ac.nz \
    --to=chris.edwards@otago.ac.nz \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.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