From: Michael Wang <wangyun@linux.vnet.ibm.com>
To: Alex Shi <alex.shi@intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>, Paul Turner <pjt@google.com>,
Mike Galbraith <efault@gmx.de>,
Andrew Morton <akpm@linux-foundation.org>,
Ram Pai <linuxram@us.ibm.com>,
"Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>,
Namhyung Kim <namhyung@kernel.org>
Subject: Re: [RFC PATCH v3 1/3] sched: schedule balance map foundation
Date: Fri, 22 Feb 2013 12:19:32 +0800 [thread overview]
Message-ID: <5126F1D4.5030308@linux.vnet.ibm.com> (raw)
In-Reply-To: <5126E705.3040308@intel.com>
On 02/22/2013 11:33 AM, Alex Shi wrote:
> On 02/22/2013 10:53 AM, Michael Wang wrote:
>>>>
>>>>>> And the final cost is 3000 int and 1030000 pointer, and some padding,
>>>>>> but won't bigger than 10M, not a big deal for a system with 1000 cpu
>>>>>> too.
>>>>
>>>> Maybe, but quadric stuff should be frowned upon at all times, these
>>>> things tend to explode when you least expect it.
>>>>
>>>> For instance, IIRC the biggest single image system SGI booted had 16k
>>>> cpus in there, that ends up at something like 14+14+3=31 aka as 2G of
>>>> storage just for your lookup -- that seems somewhat preposterous.
>> Honestly, if I'm a admin who own 16k cpus system (I could not even image
>> how many memory it could have...), I really prefer to exchange 2G memory
>> to gain some performance.
>>
>> I see your point here, the cost of space will grow exponentially, but
>> the memory of system will also grow, and according to my understanding ,
>> it's faster.
>
Hi, Alex
Thanks for your reply.
> Why not seek other way to change O(n^2) to O(n)?
>
> Access 2G memory is unbelievable performance cost.
Not access 2G memory, but (2G / 16K) memory, the sbm size is O(N).
And please notice that on 16k cpus system, topology will be deep if NUMA
enabled (O(log N) as Peter said), and that's really a good stage for
this idea to perform on, we could save lot's of recursed 'for' cycles.
>
> There are too many jokes on the short-sight of compute scalability, like
> Gates' 64K memory in 2000.
Please do believe me that I won't give up any chance to solve or lighten
this issue (like apply Mike's suggestion), and please let me know if you
have any suggestions to reduce the memory cost.
May be I could make this idea as an option, override the
select_task_rq_fair() when people want the new logical, and if they
don't want to trade with memory, just !CONFIG.
Regards,
Michael Wang
>
next prev parent reply other threads:[~2013-02-22 4:19 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 9:08 [RFC PATCH v3 0/3] sched: simplify the select_task_rq_fair() Michael Wang
2013-01-29 9:09 ` [RFC PATCH v3 1/3] sched: schedule balance map foundation Michael Wang
2013-02-20 13:21 ` Peter Zijlstra
2013-02-21 4:52 ` Michael Wang
2013-02-20 13:25 ` Peter Zijlstra
2013-02-21 4:58 ` Michael Wang
2013-02-21 11:37 ` Peter Zijlstra
2013-02-22 2:53 ` Michael Wang
2013-02-22 3:33 ` Alex Shi
2013-02-22 4:19 ` Michael Wang [this message]
2013-02-22 4:46 ` Alex Shi
2013-02-22 5:05 ` Michael Wang
2013-01-29 9:09 ` [RFC PATCH v3 2/3] sched: build schedule balance map Michael Wang
2013-01-29 9:10 ` [RFC PATCH v3 3/3] sched: simplify select_task_rq_fair() with " Michael Wang
2013-02-18 5:52 ` [RFC PATCH v3 0/3] sched: simplify the select_task_rq_fair() Michael Wang
2013-02-20 10:49 ` Ingo Molnar
2013-02-20 13:32 ` Peter Zijlstra
2013-02-20 14:05 ` Mike Galbraith
2013-02-21 5:21 ` Michael Wang
2013-02-21 5:14 ` Michael Wang
2013-02-21 4:51 ` Michael Wang
2013-02-21 6:11 ` Mike Galbraith
2013-02-21 7:00 ` Michael Wang
2013-02-21 8:10 ` Mike Galbraith
2013-02-21 9:08 ` Michael Wang
2013-02-21 9:43 ` Mike Galbraith
2013-02-22 2:36 ` Michael Wang
2013-02-22 5:02 ` Mike Galbraith
2013-02-22 5:26 ` Michael Wang
2013-02-22 6:13 ` Mike Galbraith
2013-02-22 6:42 ` Michael Wang
2013-02-22 8:17 ` Mike Galbraith
2013-02-22 8:35 ` Michael Wang
2013-02-22 8:21 ` Peter Zijlstra
2013-02-22 9:10 ` Michael Wang
2013-02-22 9:39 ` Peter Zijlstra
2013-02-22 9:58 ` Michael Wang
2013-02-21 9:20 ` Michael Wang
2013-02-21 10:20 ` Peter Zijlstra
2013-02-22 2:37 ` Michael Wang
2013-02-22 5:08 ` Mike Galbraith
2013-02-22 6:06 ` Michael Wang
2013-02-22 6:19 ` Mike Galbraith
2013-02-22 8:36 ` Peter Zijlstra
2013-02-22 9:11 ` Michael Wang
2013-02-22 9:57 ` Peter Zijlstra
2013-02-22 10:08 ` Michael Wang
2013-02-22 9:40 ` Mike Galbraith
2013-02-22 9:54 ` Ingo Molnar
2013-02-22 10:01 ` Mike Galbraith
2013-02-22 12:11 ` Ingo Molnar
2013-02-22 12:35 ` Mike Galbraith
2013-02-22 13:06 ` Ingo Molnar
2013-02-22 14:30 ` Mike Galbraith
2013-02-22 14:42 ` Mike Galbraith
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=5126F1D4.5030308@linux.vnet.ibm.com \
--to=wangyun@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alex.shi@intel.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=pjt@google.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).