Hi Dan,
On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
<[email protected]> wrote:
> Ramster does the same thing but manages it peer-to-peer across
> multiple systems using kernel sockets. One could argue that
> the dependency on sockets makes it more of a driver than "mm"
> but ramster is "memory management" too, just a bit more exotic.
How do you configure it? Can we move parts of the network protocol under
net/ramster or something?
Pekka
> From: Pekka Enberg [mailto:[email protected]]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
>
> Hi Dan,
>
> On Wed, Aug 1, 2012 at 12:13 AM, Dan Magenheimer
> <[email protected]> wrote:
> > Ramster does the same thing but manages it peer-to-peer across
> > multiple systems using kernel sockets. One could argue that
> > the dependency on sockets makes it more of a driver than "mm"
> > but ramster is "memory management" too, just a bit more exotic.
>
> How do you configure it?
Hi Pekka --
It looks like the build/configuration how-to at
https://oss.oracle.com/projects/tmem/dist/files/RAMster/HOWTO-v5-120214
is out-of-date and I need to fix some things in it. I'll post
a link to it after I update it.
> Can we move parts of the network protocol under
> net/ramster or something?
Ramster is built on top of kernel sockets. Both that networking
part and the configuration part of the ramster code are heavily
leveraged from ocfs2 and I suspect there is a lot of similarity
to gfs code as well. In the code for both of those filesystems
I think the network and configuration code lives in the same
directory with the file system, so that was the model I was following.
I'm OK with placing it wherever kernel developers want to put
it, as long as the reason is not NIMBY-ness. [1] My preference
is to keep all the parts together, at least for the review phase,
but if there is a consensus that it belongs someplace else,
I will be happy to move it.
Dan
[1] http://en.wikipedia.org/wiki/NIMBY
On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
<[email protected]> wrote:
> I'm OK with placing it wherever kernel developers want to put
> it, as long as the reason is not NIMBY-ness. [1] My preference
> is to keep all the parts together, at least for the review phase,
> but if there is a consensus that it belongs someplace else,
> I will be happy to move it.
I'd go for core code in mm/zcache.c and mm/ramster.c, and move the
clustering code under net/ramster or drivers/ramster.
> From: Pekka Enberg [mailto:[email protected]]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
>
> On Mon, Aug 6, 2012 at 5:07 PM, Dan Magenheimer
> <[email protected]> wrote:
> > I'm OK with placing it wherever kernel developers want to put
> > it, as long as the reason is not NIMBY-ness. [1] My preference
> > is to keep all the parts together, at least for the review phase,
> > but if there is a consensus that it belongs someplace else,
> > I will be happy to move it.
>
> I'd go for core code in mm/zcache.c and mm/ramster.c, and move the
> clustering code under net/ramster or drivers/ramster.
Hi Pekka --
Thanks for the quick feedback!
Hmmm.. there's also zbud.c and tmem.c which are critical components
of both zcache and ramster. And there are header files as well which
will need to either be in mm/ or somewhere in include/linux/
Is there a reason or rule that mm/ can't have subdirectories?
Since zcache has at least three .c files plus ramster.c, and
since mm/frontswap.c and mm/cleancache.c are the foundation on
which all of these are built, I was thinking grouping all six
(plus headers) in the same mm/tmem/ subdirectory was a good
way to keep mm/ from continuing to get more cluttered... not counting
new zcache and ramster files, there are now 74 .c files in mm/!
(Personally, I think a directory has too many files in it if
"ls" doesn't fit in a 25x80 window.)
Thoughts?
Dan
On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
<[email protected]> wrote:
> Hmmm.. there's also zbud.c and tmem.c which are critical components
> of both zcache and ramster. And there are header files as well which
> will need to either be in mm/ or somewhere in include/linux/
>
> Is there a reason or rule that mm/ can't have subdirectories?
>
> Since zcache has at least three .c files plus ramster.c, and
> since mm/frontswap.c and mm/cleancache.c are the foundation on
> which all of these are built, I was thinking grouping all six
> (plus headers) in the same mm/tmem/ subdirectory was a good
> way to keep mm/ from continuing to get more cluttered... not counting
> new zcache and ramster files, there are now 74 .c files in mm/!
> (Personally, I think a directory has too many files in it if
> "ls" doesn't fit in a 25x80 window.)
>
> Thoughts?
There's no reason we can't have subdirectories. That said, I really
don't see the point of having a separate directory called 'tmem'. It
might make sense to have mm/zcache and/or mm/ramster but I suspect
you can just fold the core code in mm/zcache.c and mm/ramster.c by
slimming down the weird Solaris-like 'tmem' abstractions.
Pekka
> From: Pekka Enberg [mailto:[email protected]]
> Subject: Re: [RFC/PATCH] zcache/ramster rewrite and promotion
>
> On Mon, Aug 6, 2012 at 7:10 PM, Dan Magenheimer
> <[email protected]> wrote:
> > Hmmm.. there's also zbud.c and tmem.c which are critical components
> > of both zcache and ramster. And there are header files as well which
> > will need to either be in mm/ or somewhere in include/linux/
> >
> > Is there a reason or rule that mm/ can't have subdirectories?
> >
> > Since zcache has at least three .c files plus ramster.c, and
> > since mm/frontswap.c and mm/cleancache.c are the foundation on
> > which all of these are built, I was thinking grouping all six
> > (plus headers) in the same mm/tmem/ subdirectory was a good
> > way to keep mm/ from continuing to get more cluttered... not counting
> > new zcache and ramster files, there are now 74 .c files in mm/!
> > (Personally, I think a directory has too many files in it if
> > "ls" doesn't fit in a 25x80 window.)
> >
> > Thoughts?
>
> There's no reason we can't have subdirectories. That said, I really
> don't see the point of having a separate directory called 'tmem'. It
> might make sense to have mm/zcache and/or mm/ramster but I suspect
> you can just fold the core code in mm/zcache.c and mm/ramster.c by
> slimming down the weird Solaris-like 'tmem' abstractions.
I'm not sure I understand... what is Solaris-like about tmem?
And what would you slim down?
While I agree one can often glom three separate 1000-line .c files
into a single 3000-line .c file, I recently spent some time moving
the other direction to, I thought, improve readability. Do kernel
developers have a preference for huge .c files rather than smaller
logically-separated moderate-sized files in a subdirectory?
Thanks,
Dan