public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zoltan Menyhart <Zoltan.Menyhart_AT_bull.net@nospam.org>
To: Erich Focht <efocht@hpce.nec.com>
Cc: linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Migrate pages from a ccNUMA node to another
Date: Tue, 30 Mar 2004 11:57:08 +0200	[thread overview]
Message-ID: <40694474.50776A10@nospam.org> (raw)
In-Reply-To: 200403300116.01877.efocht@hpce.nec.com

Erich Focht wrote:
> 
> Szia Zoltan,
> 
> > - Migrate pages identified by their physical addresses to another NUMA node
> You want this only for your "AI" keeping track of the hw counters in
> the chipset? I hope you can teach it to keep track of the bandwidth of
> all processes on the machine, otherwise it might disturb the processes
> more than it helps them... and waste the machine's bandwidth with
> migrating pages.

Szervusz Erich,

I put AI between quotation marks because it is not a real intelligence.
It should not waste much time on being intelligent :-)
At least we have not managed to find out a general purpose solution that
could cope with no matter what application.
We try to tune parameters, like sampling period / time, how many pages
are checked, when we consider a page as "hot", how many % or # cycles
distant vs. local justifies the migration...
We try to set up a "profile" for an application.
The launcher of the application takes into account the profile and
the AI evaluates the HW counters according this profile info.
I think most of the huge applications of our clients will run several
times with different data but with the data of similar behavior.
The clients will have the ability to tune their application profiles. 

> > - Migrate pages of a virtual user address range to another NUMA node
> This is good. I'm thinking about the rss/node patches, they would tell
> you when you should think about migrating something for a process. My
> current usage model would be simpler: for a given mm migrate all pages
> currently on node A to node B. But the flexibility of your API will
> certainly not remain unused.

You should migrate if it worth the cost of the migration to do
(private malloc()-ed data, stack,...).

Do you mean to guess in the kernel what pages to move ?

I need "real information" :-)) to decide, this is either I ask the HW or
I wait the application to tell me its requirement.

> > BTW Has someone a machine with a chip set other than i82870 ?
> ??? As far as I know SGI, HP, NEC and IBM have all their own NUMA
> chipsets for IA64. Was this the question? Are you looking for hardware
> counters?

I'd like to know - and someone to try :-)) - how much it costs on another
chip set to measure the page usage statistics, say for 1 Gbytes of memory...

Thanks,

Zoltán

  reply	other threads:[~2004-03-30  9:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-26  9:02 Migrate pages from a ccNUMA node to another Zoltan Menyhart
2004-03-26 10:39 ` Robin Holt
2004-03-26  7:10   ` Andi Kleen
2004-03-26 12:38   ` Zoltan Menyhart
2004-03-29 23:16 ` Erich Focht
2004-03-30  9:57   ` Zoltan Menyhart [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-03-26  9:18 Migrate pages from a ccNUMA node to another - patch Zoltan Menyhart
2004-03-26 17:20 ` Dave Hansen
2004-03-30 11:39   ` Zoltan Menyhart
2004-03-30 15:58     ` Dave Hansen
2004-04-01  8:44       ` Migrate pages from a ccNUMA node to another Zoltan Menyhart
2004-03-30 11:20 Migrate pages from a ccNUMA node to another - patch Zoltan Menyhart
2004-03-30 12:08 ` Hirokazu Takahashi
2004-03-30 14:32   ` Zoltan Menyhart
2004-04-03  2:58     ` Hirokazu Takahashi
2004-04-05 15:07       ` Zoltan Menyhart
2004-04-05 15:40         ` Dave Hansen
2004-04-06 14:42           ` Migrate pages from a ccNUMA node to another Zoltan Menyhart

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=40694474.50776A10@nospam.org \
    --to=zoltan.menyhart_at_bull.net@nospam.org \
    --cc=Zoltan.Menyhart@bull.net \
    --cc=efocht@hpce.nec.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@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