All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr Natalenko <oleksandr@natalenko.name>
To: ValdikSS <iam@valdikss.org.ru>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Alexey Avramov <hakavlad@inbox.lv>,
	linux-mm@kvack.org, linux-doc@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	corbet@lwn.net, mcgrof@kernel.org, keescook@chromium.org,
	yzaikin@google.com, kernel@xanmod.org, aros@gmx.com,
	hakavlad@gmail.com, Yu Zhao <yuzhao@google.com>
Subject: Re: [PATCH] mm/vmscan: add sysctl knobs for protecting the working set
Date: Fri, 03 Dec 2021 15:01:08 +0100	[thread overview]
Message-ID: <4776971.31r3eYUQgx@natalenko.name> (raw)
In-Reply-To: <20211202135824.33d2421bf5116801cfa2040d@linux-foundation.org>

Hello.

On čtvrtek 2. prosince 2021 22:58:24 CET Andrew Morton wrote:
> On Thu, 2 Dec 2021 21:05:01 +0300 ValdikSS <iam@valdikss.org.ru> wrote:
> > This patchset is surprisingly effective and very useful for low-end PC
> > with slow HDD, single-board ARM boards with slow storage, cheap Android
> > smartphones with limited amount of memory. It almost completely prevents
> > thrashing condition and aids in fast OOM killer invocation.
> > 
> > The similar file-locking patch is used in ChromeOS for nearly 10 years
> > but not on stock Linux or Android. It would be very beneficial for
> > lower-performance Android phones, SBCs, old PCs and other devices.
> > 
> > With this patch, combined with zram, I'm able to run the following
> > software on an old office PC from 2007 with __only 2GB of RAM__
> > 
> > simultaneously:
> >   * Firefox with 37 active tabs (all data in RAM, no tab unloading)
> >   * Discord
> >   * Skype
> >   * LibreOffice with the document opened
> >   * Two PDF files (14 and 47 megabytes in size)
> > 
> > And the PC doesn't crawl like a snail, even with 2+ GB in zram!
> > Without the patch, this PC is barely usable.
> > Please watch the video:
> > https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/en/
> 
> This is quite a condemnation of the current VM.  It shouldn't crawl
> like a snail.
> 
> The patch simply sets hard limits on page reclaim's malfunctioning.
> I'd prefer that reclaim not malfunction :(
> 
> That being said, I can see that a blunt instrument like this would be
> useful.
> 
> I don't think that the limits should be "N bytes on the current node".
> Nodes can have different amounts of memory so I expect it should scale
> the hard limits on a per-node basis.  And of course, the various zones
> have different size as well.

Probably not. To my understanding, the limits should roughly correspond to 
what you see after executing this:

```
$ echo 1 | sudo tee /proc/sys/vm/drop_caches; grep -F 'Active(file)' /proc/
meminfo
```

IMO, this has nothing to do with the size of the node.

> We do already have a lot of sysctls for controlling these sort of
> things.  Was much work put into attempting to utilize the existing
> sysctls to overcome these issues?

-- 
Oleksandr Natalenko (post-factum)



  parent reply	other threads:[~2021-12-03 14:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 11:16 [PATCH] mm/vmscan: add sysctl knobs for protecting the working set Alexey Avramov
2021-11-30 15:28 ` Luis Chamberlain
2021-11-30 16:15 ` kernel test robot
2021-11-30 16:15   ` kernel test robot
2021-11-30 17:37 ` kernel test robot
2021-11-30 18:56 ` Oleksandr Natalenko
2021-12-01 15:51   ` Alexey Avramov
2021-12-02 18:05 ` ValdikSS
2021-12-02 21:58   ` Andrew Morton
2021-12-03 11:59     ` Vlastimil Babka
2021-12-03 13:27       ` Alexey Avramov
2021-12-06  9:59         ` Michal Hocko
2022-01-09 22:59           ` Barry Song
2021-12-03 14:01     ` Oleksandr Natalenko [this message]
2021-12-12 20:15     ` Alexey Avramov
2021-12-13  9:06       ` Barry Song
2021-12-13  9:07       ` Michal Hocko
2021-12-13  8:38   ` Barry Song
2022-01-25  8:19     ` ValdikSS
2022-02-12  0:01       ` Barry Song

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=4776971.31r3eYUQgx@natalenko.name \
    --to=oleksandr@natalenko.name \
    --cc=akpm@linux-foundation.org \
    --cc=aros@gmx.com \
    --cc=corbet@lwn.net \
    --cc=hakavlad@gmail.com \
    --cc=hakavlad@inbox.lv \
    --cc=iam@valdikss.org.ru \
    --cc=keescook@chromium.org \
    --cc=kernel@xanmod.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=yuzhao@google.com \
    --cc=yzaikin@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.