Re: [GIT PULL] mm: frontswap (for 3.2 window)
From: KAMEZAWA Hiroyuki
Date: Mon Oct 31 2011 - 20:52:02 EST
On Mon, 31 Oct 2011 09:38:12 -0700 (PDT)
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> > From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@xxxxxxxxxxxxxx]
> > Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)
> Hi Kame --
> Thanks for your reply and for your earlier reviews of frontswap,
> and my apologies that I accidentally left you off of the Cc list \
> for the basenote of this git-pull request.
> > I don't have heavy concerns to the codes itself but this process as bypassing -mm
> > or linux-next seems ugly.
> First, frontswap IS in linux-next and it has been since June 3
> and v11 has been in linux-next since September 23. This
> is stated in the base git-pull request.
Ok, I'm sorry. I found frontswap.c in my tree.
> > Why bypass -mm tree ?
> > I think you planned to merge this via -mm tree and, then, posted patches
> > to linux-mm with CC -mm guys.
> Hmmm... the mm process is not clear or well-documented.
not complicated to me.
post -> akpm's -mm tree -> mainline.
But your tree seems to be in -mm via linux-next. Hmm, complicated ;(
I'm sorry I didn't notice frontswap.c was there....
> > I think you posted 2011/09/16 at the last time, v10. But no further submission
> > to gather acks/reviews from Mel, Johannes, Andrew, Hugh etc.. and no inclusion
> > request to -mm or -next. _AND_, IIUC, at v10, the number of posted pathces was 6.
> > Why now 8 ? Just because it's simple changes ?
> See https://lkml.org/lkml/2011/9/21/373. Konrad Wilk
> helped me to reorganize the patches (closer to what you
> suggested I think), but there were no code changes between
> v10 and v11, just dividing up the patches differently
> as Konrad thought there should be more smaller commits.
> So no code change between v10 and v11 but the number of
> patches went from 6 to 8.
> My last line in that post should also make it clear that
> I thought I was done and ready for the 3.2 window, so there
> was no evil intent on my part to subvert a process.
> It would have been nice if someone had told me there
> were uncompleted steps in the -mm process or, even better,
> pointed me to a (non-existent?) document where I could see
> for myself if I was missing steps!
> So... now what?
As far as I know, patches for memory management should go through akpm's tree.
And most of developpers in that area see that tree.
Now, your tree goes through linux-next. It complicates the problem.
When a patch goes through -mm tree, its justification is already checked by
, at least, akpm. And while in -mm tree, other developpers checks it and
some improvements are done there.
Now, you tries to push patches via linux-next and your
justification for patches is checked _now_. That's what happens.
It's not complicated. I think other linux-next patches are checked
its justification at pull request.
So, all your work will be to convice people that this feature is
necessary and not-intrusive, here.
>From my point of view,
- I have no concerns with performance cost. But, at the same time,
I want to see performance improvement numbers.
- At discussing an fujitsu user support guy (just now), he asked
'why it's not designed as device driver ?"
I couldn't answered.
So, I have small concerns with frontswap.ops ABI design.
Do we need ABI and other modules should be pluggable ?
Can frontswap be implemented as something like
# setup frontswap via device-mapper or some.
# swapon /dev/frontswap
It seems required hooks are just before/after read/write swap device.
other hooks can be implemented in notifier..no ?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/