public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: linux-ia64@vger.kernel.org
Subject: Re: elf header bits for page migration support......
Date: Fri, 13 May 2005 14:10:23 +0000	[thread overview]
Message-ID: <20050513141023.GB24961@lucon.org> (raw)
In-Reply-To: <42847F6B.3080609@engr.sgi.com>

On Fri, May 13, 2005 at 05:20:27AM -0500, Ray Bryant wrote:
> Tony,
> 
> As some of the readers of this list may know, I've been working on a
> "manual page migration" facility for Altix.   Basically this is intended
> to allow a batch manager to move applications around on a large NUMA
> system.  Further details and discussion can be found on the linux-mm
> lists, for example the thread starting at:
> 
> http://marc.theaimsgroup.com/?l=linux-mm&m\x111578651020174&w=2
> 
> Now given the existence of the memory migration code in the memory
> hotplug patch, the hard part of this project is not doing the migration,
> but figuring out what not to migrate (e. g. one doesn't want to migrate
> the shared pages of a shared library, for example).  Currently, we are
> flagging files as libraries by using a file system extended attribute.
> But this is meeting with some resistance.
> 
> The alternative being suggested is to mark the elf header of object files
> that should only have shared pages migrated, or that should not be migrated
> (e. g. you don't want to migrate /bin/csh all the time.)
> 
> (We'll extend mmap() with a similar set of flags.)
> 
> So the question has come up, which bits in the elf header are available
> for such use.  Apparently there is a bit of a muddle here and we need to
> get the "community" to agree.

Bits in elf header are very scare. Can you use an ELF segment like
PT_GNU_EH_FRAME and PT_GNU_STACK?


H.J.

  reply	other threads:[~2005-05-13 14:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 10:20 elf header bits for page migration support Ray Bryant
2005-05-13 14:10 ` H. J. Lu [this message]
2005-05-13 17:54 ` Luck, Tony
2005-05-16  9:41 ` Peter Chubb

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=20050513141023.GB24961@lucon.org \
    --to=hjl@lucon.org \
    --cc=linux-ia64@vger.kernel.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