linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Larry Woodman <lwoodman@redhat.com>
To: Rik van Riel <riel@redhat.com>
Cc: lsf-pc@lists.linux-foundation.org,
	Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC][ATTEND] topics I'd like to discuss
Date: Fri, 22 Feb 2013 17:37:13 -0500	[thread overview]
Message-ID: <5127F319.2090302@redhat.com> (raw)
In-Reply-To: <5127E601.6080202@redhat.com>

On 02/22/2013 04:41 PM, Rik van Riel wrote:
> On 02/22/2013 10:35 AM, Larry Woodman wrote:
>> 1.) Using mmu notifiers to set up the page tables for integrated
>> devices(GPUs) and allowing the generic
>>       kernel pagefault handler to resolve translations for those 
>> devices.
>
> This functionality is also desired by people who want to run
> memory coherency over infiniband and some other very fast
> network fabrics, as well as by the people who want to offload
> work to specialized cores in their system.
>
> Since there are multiple use cases for this kind of functionality,
> I believe that it is important we get the infrastructure right,
> and discussing this topic at LSF/MM sounds like a good idea.
Agreed.
>
>> 2.) Replication of pagecache pages on NUMA nodes.
>
> What about this would you like to discuss?
The tradeoffs between local memory access for frequently referenced 
read-only/executable
pages like shared library text and the additional memory consumption 
associated replicating
pages on multiple NUMA nodes.
>
> Is there some proposal of code to do this?
Not yet, I implemented replication of filesystem cache memory on each 
NUMA node
several years ago for a UNIX kernel when NUMA systems first appeared.  
At that
time both memory and caches were much smaller than they are now so the 
tradeoffs
between local memory access and inducing page reclamation were different 
than they
are now.  However there was a significant performance boost on memory 
rich systems
running applications with bloated text sections.

Larry


--
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:[~2013-02-22 22:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <51279035.5050304@redhat.com>
2013-02-22 21:41 ` [Lsf-pc] [LSF/MM TOPIC][ATTEND] topics I'd like to discuss Rik van Riel
2013-02-22 22:37   ` Larry Woodman [this message]
2013-02-22 22:38   ` Dave Hansen

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=5127F319.2090302@redhat.com \
    --to=lwoodman@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=riel@redhat.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;
as well as URLs for NNTP newsgroup(s).