Hi Stephen --
Please re-include the following tree into linux-next. The
commit series is for frontswap, the complement of cleancache
handling swap pages, which is the next phase in tmem. It also
includes the shim code to Xen tmem for frontswap. It applies
cleanly on linux-3.0-rc1, but if there are any problems or
you have any questions, please let me know!
git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem.git#linux-next
Thanks,
Dan
Hi Dan,
On Tue, 31 May 2011 17:49:21 -0700 (PDT) Dan Magenheimer <[email protected]> wrote:
>
> Please re-include the following tree into linux-next. The
> commit series is for frontswap, the complement of cleancache
> handling swap pages, which is the next phase in tmem. It also
> includes the shim code to Xen tmem for frontswap. It applies
> cleanly on linux-3.0-rc1, but if there are any problems or
> you have any questions, please let me know!
>
> git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem.git#linux-next
I don't remove trees from linux-next unless excplictly asked to, so this
tree is still included. As long as you stick to the rules (posted,
reviewed, ready for Linus), anything you add to that tree will be
included.
The tree is still called "cleancache" in linux-next. Should I change
that to something more generic?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
> On Tue, 31 May 2011 17:49:21 -0700 (PDT) Dan Magenheimer
> <[email protected]> wrote:
> >
> > Please re-include the following tree into linux-next. The
> > commit series is for frontswap, the complement of cleancache
> > handling swap pages, which is the next phase in tmem. It also
> > includes the shim code to Xen tmem for frontswap. It applies
> > cleanly on linux-3.0-rc1, but if there are any problems or
> > you have any questions, please let me know!
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/djm/tmem.git#linux-next
>
> I don't remove trees from linux-next unless excplictly asked to, so
> this
> tree is still included
Hi Stephen --
OK, I see "Already up-to-date" in merge.log. I'll assume
that the new frontswap commits will lag a day. (Thanks,
Konrad, for helping me find this info and pointing out the
probable lag.)
(A thought... perhaps the merge.log generation script should
do a "date" at the beginning and end, so one knows if one
has just missed your merge window?)
> As long as you stick to the rules (posted,
> reviewed, ready for Linus), anything you add to that tree will be
> included.
Yep, understood. Frontswap has been posted on lkml and tested for
over a year (and for nearly 2-1/2 years if counting earlier
versions as part of the original tmem postings), but hasn't gotten
as much attention because it was serialized behind merging of cleancache.
> The tree is still called "cleancache" in linux-next. Should I change
> that to something more generic?
Yes please. A good short name would be "tmem", but if you want
something longer and more descriptive maybe, "transcendent_memory".
I expect in the future that this might be the path for, for
example, tmem-related code that is promoted from drivers/staging.
E.g., the generic tmem.c code in drivers/staging/zcache could
probably end up in lib at some point if/when there are multiple users.
Thanks!
Dan
Hi Dan,
On Wed, 1 Jun 2011 09:22:59 -0700 (PDT) Dan Magenheimer <[email protected]> wrote:
>
> OK, I see "Already up-to-date" in merge.log. I'll assume
> that the new frontswap commits will lag a day. (Thanks,
> Konrad, for helping me find this info and pointing out the
> probable lag.)
>
> (A thought... perhaps the merge.log generation script should
> do a "date" at the beginning and end, so one knows if one
> has just missed your merge window?)
Yeah, well I am out of sync (timezone-wise) with most people, so good
thought. Though I actually fetch all the trees before I starte merging
them, but it will give people some idea.
> > The tree is still called "cleancache" in linux-next. Should I change
> > that to something more generic?
>
> Yes please. A good short name would be "tmem", but if you want
> something longer and more descriptive maybe, "transcendent_memory".
> I expect in the future that this might be the path for, for
> example, tmem-related code that is promoted from drivers/staging.
> E.g., the generic tmem.c code in drivers/staging/zcache could
> probably end up in lib at some point if/when there are multiple users.
OK, I have renamed it to tmem (much easier to type :-)).
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/