linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mandeep Singh Baines <msb@chromium.org>
To: lsf-pc@lists.linux-foundation.org
Cc: Luigi Semenzato <semenzato@chromium.org>,
	linux-mm@kvack.org, Olof Johansson <olofj@chromium.org>
Subject: [ATTEND] Linux Storage, FS & MM Summit 2012: Memory management challenges for embedded systems
Date: Tue, 7 Feb 2012 09:23:15 -0800	[thread overview]
Message-ID: <CACBanvqb2VnVeHC33wZdE5OY61LgC_NiptmaCVvjn4fKEXaByw@mail.gmail.com> (raw)

Hi,

Please pardon the late submission.

I'd like to propose "Memory management challenges for embedded
systems" as an agenda topic for the Linux Storage, Filesystem, and
Multimedia Summit in San Francisco.

I am a kernel developer on the ChromiumOS project. I work on a number
of different areas of the kernel but memory management is definitely a
key focus area for our team and myself.

ChromiumOS much like a typical embedded system in that the resources
are constrained and the entire system is tuned for one application: in
our case, the browser.

>From an MM perspective, we've avoided using memory containment since
there is just a single application. For security, we avoid swap (no
unencrypted user data on persistent store). We also avoid swap because
of the variability it adds to latency. Since we don't have swap,
running out of memory is a constant challenge. We don't mind OOMing
but prefer it would happen quickly to avoid thrashing. We've used a
tiny hack in order to make this happen:

http://lwn.net/Articles/412313/

The hack requires us to predict working set size, it would be nice if
the kernel automatically calculated it. It would be nice if vmscan's
active and inactive list modeled the real working set. We have some
ideas on how to do that:

https://lkml.org/lkml/2010/11/3/394

Or perhaps it would be preferable to avoid OOM and instead let
user-space take some action:

http://lwn.net/Articles/475791/

But letting userspace take action on behalf of the kernel is always
tricky so maybe it would be better have something like tmem in
userspace:

http://lwn.net/Articles/468896/
http://lwn.net/Articles/340080/

Regards,
Mandeep

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

                 reply	other threads:[~2012-02-07 17:23 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=CACBanvqb2VnVeHC33wZdE5OY61LgC_NiptmaCVvjn4fKEXaByw@mail.gmail.com \
    --to=msb@chromium.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=olofj@chromium.org \
    --cc=semenzato@chromium.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;
as well as URLs for NNTP newsgroup(s).