Re: [GIT PULL] mm: frontswap (for 3.2 window)

[KAMEZAWA Hiroyuki]

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 ?

Thanks,
-Kame

--
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/