linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Antonio Vargas <wind@cocodriloo.com>
Cc: 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 08:39:05 -0700	[thread overview]
Message-ID: <12790000.1050334744@[10.10.2.4]> (raw)
In-Reply-To: <20030414152947.GB14552@wind.cocodriloo.com>

> 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 ;-) 

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, 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.

  reply	other threads:[~2003-04-14 15:28 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 [this message]
2003-04-14 15:57       ` Antonio Vargas
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='12790000.1050334744@[10.10.2.4]' \
    --to=mbligh@aracnet.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicoya@apia.dhs.org \
    --cc=tmiller10@cfl.rr.com \
    --cc=wind@cocodriloo.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).