public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Theodore Tso <tytso@MIT.EDU>
Cc: Andi Kleen <andi@firstfloor.org>, Cyrus Massoumi <cyrusm@gmx.net>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Kernel Scalability to 48 cores
Date: Tue, 12 Oct 2010 19:02:10 +0200	[thread overview]
Message-ID: <20101012170210.GI20436@basil.fritz.box> (raw)
In-Reply-To: <585FC89B-C279-485E-9AE4-6ABA0F5EE4CE@mit.edu>

On Tue, Oct 12, 2010 at 12:00:27PM -0400, Theodore Tso wrote:
> 
> On Oct 12, 2010, at 10:33 AM, Andi Kleen wrote:
> 
> > The paper is known, but it seems to be in the usual unproductive 
> > "publish a paper, but don't care about fixing anything" acedemic mode.
> 
> The thing I found most disappointing about the paper is that it describe techniques that have been in use in industry to provide better scalability to commerical OS's, and which were first applied to Linux something like a decade ago.


I haven't gone fully through it yet, maybe there are still some useful
nuggets in there. I would help if they published their patches though.

They used a few new workloads which were useful I guess.

> It's just that a lot of scalability work took a bit of a hiatus, oh, five years ago because at the time, Linux was good enough, and adding more scalability has costs (which is why not all of the changes SGI made for 512 and 1024-way scalability have not necessarily found their way into mainline).   The fact that we've needed to worry about scalability now that 6+ cores/socket are available now, and many more are coming soon, is something we've known for at least the last year or two. 

Already at 8*2 and 12 cores/socket

Fully agreed, but the other aspect is that we also need to worry
now about TBs and more of memory on a single (non extreme) system

More cores come with more memory and now even with 4K pages.

As a simple exercise I configured a 1TB system for less than 50kEUR
at Dell.com some time ago: that's not cheap, but definitely not
an exotic super computer either and prices will go down.

I believe a lot of new challenges also come from that, although
there has been a lot less work on that so far than on core scalability.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

      reply	other threads:[~2010-10-12 17:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-11 21:30 Kernel Scalability to 48 cores Cyrus Massoumi
2010-10-11 22:55 ` Diego Calleja
2010-10-12 14:33 ` Andi Kleen
2010-10-12 16:00   ` Theodore Tso
2010-10-12 17:02     ` Andi Kleen [this message]

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=20101012170210.GI20436@basil.fritz.box \
    --to=andi@firstfloor.org \
    --cc=cyrusm@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@MIT.EDU \
    /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