From: Christopher Lameter <cl@linux.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org
Subject: [LSF/MM ATTEND] Large memory issues, new fragmentation avoidance scheme
Date: Wed, 31 Jan 2018 17:42:40 -0600 (CST) [thread overview]
Message-ID: <alpine.DEB.2.20.1801311730400.21179@nuc-kabylake> (raw)
Would like to attend the upcoming summit and would be interested in
participating in the large memory discussions (including NVRAM, DAX) as
well as improvements in huge page support (pagecache, easy
configurability, consistency over multiple sizes of huge pages etc etc)
Also an important subject matter would be to investigate ways to improve
I/O throughput from memory for large scale datasets (1TB or higher). Maybe
this straddles a bit into the FS part too.
Recently stumbled over another way to avoid fragmentation by reserving
certain numbers of sizes of each page order. This seems to be deployed at
a large ISP for years now and working out ok. Maybe another stab at the
problem of availability of higher. Would like to discuss if this approach
could be upstreamed.
Then I'd like to continue explore ways to avoid fragmentation like movable
objects in slab caches (see the xarray implementation for example).
Coming up with an inode/dentry targeted reclaim/move approach would also
be interesting in particular since these already have _isolate_ functions
and are akin to the early steps in page migration where the focused on
targeted reclaim (and then reloading the page from swap) to simplify the
approach rather than making page actually movable.
There are numerous other issues with large memory and throughput of
extreme HPC loads that my coworkers are currently running into. Would be
good to share experiences and figure out ways to address these.
--
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-31 23:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=alpine.DEB.2.20.1801311730400.21179@nuc-kabylake \
--to=cl@linux.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.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