lkml.org 
[lkml]   [2001]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: SMP/cc Cluster description
On Thu, Dec 06, 2001 at 03:19:45PM -0800, David S. Miller wrote:
> From: Larry McVoy <lm@bitmover.com>
> Date: Thu, 6 Dec 2001 15:15:04 -0800
>
> Wait a second, you're missing something. If you are going to make a single
> OS image work on a 64 way (or whatever) SMP, you have all of these issues,
> right? I'm not introducing additional locking problems with the design.
>
> And you're not taking any of them away from the VFS layer. That is
> where all the real fundamental current scaling problems are in the
> Linux kernel.

Sure I am, but I haven't told you how. Suppose that your current
VFS can handle N cpus byt you have N*M cpus. Take a look at
http://bitmover.com/lm/papers/bigfoot.ps and imagine applying that
technique here. To summarize what I'm proposing, the locking problems are
because too many cpus want at the same data structures at the same time.
One way to solve that is to fine grain thread the data structures, and
that is a pain in the ass. Another way to solve it may be to "stripe"
the file "servers". Imagine each CPU serving up a part of a bigfoot
file system. I've just reduced the scaling problems by a factor of M.

And, the ccCluster approach moves most of the nasty locking
problems into a ccCluster specific filesystem rather than buggering up
the generic paths.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:13    [W:0.259 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site