linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Vinayak Menon <vinmenon@codeaurora.org>,
	Rik van Riel <riel@redhat.com>, Jan Kara <jack@suse.cz>,
	Minchan Kim <minchan@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Will Deacon <will.deacon@arm.com>, linux-mm <linux-mm@kvack.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Huang Ying <ying.huang@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Mel Gorman <mgorman@suse.de>
Subject: Re: [PATCH 1/2] mm: make faultaround produce old ptes
Date: Tue, 5 Dec 2017 08:39:16 -0800	[thread overview]
Message-ID: <CA+55aFyFc-+pAx80zx0xsYpCiU25KUFVzUEL=z-gj+iRDzUgbQ@mail.gmail.com> (raw)
In-Reply-To: <20171205121614.ek45btdgrpbmvf45@armageddon.cambridge.arm.com>

On Tue, Dec 5, 2017 at 4:16 AM, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> I would be more in favour of some heuristics to dynamically reduce the
> fault-around bytes based on the memory pressure rather than choosing
> between young or old ptes. Or, if we are to go with old vs young ptes,
> make this choice dependent on the memory pressure regardless of whether
> the CPU supports hardware accessed bit.

That sounds like a good idea, but possibly a bit _too_ smart for
something that likely isn't a big deal.

The current behavior definitely is based on a "swapping is not a big
deal" mindset, and that getting the best LRU isn't worth it. That's
probably true in most circumstances, but if you really do have low
memory, and you really do have fairly random access behavior that
where the actual working set size is close to the actual memory size,
then a "get rid of faultaround pages earlier" mode would be a good
thing.

So I'm not at all against your idea - it sounds like the
RightThing(tm) to do - I just wonder how painful it is to generate a
sane heuristic that actually works in practice..

                  Linus

--
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:[~2017-12-05 16:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-28  5:07 Vinayak Menon
2017-11-28  5:07 ` [PATCH 2/2] arm64: add faultaround mm hook Vinayak Menon
2017-11-28  9:12 ` [PATCH 1/2] mm: make faultaround produce old ptes Jan Kara
2017-11-29  5:03   ` Vinayak Menon
2017-11-28 19:45 ` Linus Torvalds
2017-11-29  6:05   ` Vinayak Menon
2017-11-29 10:51     ` Will Deacon
2017-11-29 11:24       ` Vinayak Menon
2017-11-29 17:37       ` Linus Torvalds
2017-12-05 12:16   ` Catalin Marinas
2017-12-05 16:39     ` Linus Torvalds [this message]
2017-12-11  7:01     ` Vinayak Menon

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='CA+55aFyFc-+pAx80zx0xsYpCiU25KUFVzUEL=z-gj+iRDzUgbQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jack@suse.cz \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=vinmenon@codeaurora.org \
    --cc=will.deacon@arm.com \
    --cc=ying.huang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox