From: Antonio Vargas <wind@cocodriloo.com>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Antonio Vargas <wind@cocodriloo.com>,
Timothy Miller <tmiller10@cfl.rr.com>,
linux-kernel@vger.kernel.org, nicoya@apia.dhs.org
Subject: Re: Quick question about hyper-threading (also some NUMA stuff)
Date: Mon, 14 Apr 2003 17:57:48 +0200 [thread overview]
Message-ID: <20030414155748.GD14552@wind.cocodriloo.com> (raw)
In-Reply-To: <12790000.1050334744@[10.10.2.4]>
On Mon, Apr 14, 2003 at 08:39:05AM -0700, Martin J. Bligh wrote:
> > Perhaps it would be good to un-COW pages:
> >
> > 1. fork process
> > 2. if current node is not loaded, continue as usual
> > 3. if current node is loaded:
> > 3a. pick unloaded node
> > 4b. don't do COW for data pages, but simply copy them to node-local memory
> >
> > This way, read-write sharings would be replicated for each node.
>
> Sharing read-write stuff is a total nightmare - you have to deal with
> all the sync stuff, and invalidation. In real-life scenarios, I really
> doubt the complexity is worth it - read-only is quite complex enough,
> thanks ;-)
I mean MAP_PRIVATE stuff, not MAP_SHARED.
> Theoretically, if you had some pages that were predominatly read-only,
> and very occasionally got written to, it *might* be worth it.
> But probably not ;-)
>
> > Also, keeping an per-node active-page-list and then forcefully copying
> > the page to a node-local page-frame when accesing a page which is
> > active on another node could be good.
>
> Not sure what you mean by this. wrt the active-page list here's a per-node
> LRU already. Or you mean something on a per-address-space basis?
Yes, I meant a per-node active LRU. I'd better get a closer look
at what's already done ;)
> Yes, faulting the pages in lazily from another node as we touch them is
> probably the right thing to do. Giving secondary copies some LRU disadvantage
> (perhaps always keeping them on the inactive list, never the active),
> would be fun, but then you get into the whole "who is the primary owner,
> and what do we do when they ditch the page" complexity. The node bitmap
> I suggested earlier might help. But I'd rather keep it simple at first ;-)
>
> M.
Antonio.
next prev parent reply other threads:[~2003-04-14 15:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-14 13:31 Quick question about hyper-threading (also some NUMA stuff) Timothy Miller
2003-04-14 14:55 ` Martin J. Bligh
2003-04-14 15:29 ` Antonio Vargas
2003-04-14 15:39 ` Martin J. Bligh
2003-04-14 15:57 ` Antonio Vargas [this message]
2003-04-14 16:24 ` Martin J. Bligh
2003-04-14 16:43 ` Antonio Vargas
2003-04-14 16:37 ` Martin J. Bligh
2003-04-14 17:14 ` Antonio Vargas
2003-04-14 17:22 ` Martin J. Bligh
2003-04-14 18:32 ` cow-ahead N pages for fault clustering Antonio Vargas
2003-04-14 18:47 ` Antonio Vargas
2003-04-15 5:49 ` Martin J. Bligh
2003-04-18 17:35 ` Antonio Vargas
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=20030414155748.GD14552@wind.cocodriloo.com \
--to=wind@cocodriloo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=nicoya@apia.dhs.org \
--cc=tmiller10@cfl.rr.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.