[RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel

[RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel

[Akira Hayakawa]

Hi, DM Guys,

I am thinking of a little design change
as to autonomous migration feature.
I want to share this issue with you
to first ask for your advice
and for you to deeply understand the 
functionality of dm-writeboost at the same time.


dm-writeboost has a daemon that autonomouly turn on/off migration.
Migration means writing back from cache device to backing store.
The daemon checking the load of backing stores
and turn on/off migration accoding to the load.
Migration despite the backing store in high load
causes long queuing to the backing store
that makes the situation even worse.

The daemon is now implemented in Python using PythonDaemon module
since the daemon is not essential for dm-writeboost kernel module
to run without failure.

My idea is to port this daemon to in-kernel.

The reasons are:
1. The daemon can be said to be "nearly" essential.
   Who wants to use dm-writeboost without the daemon is my question.
   I think none.
2. Functionality of the kernel module should be self-sufficient in kernel.
3. I think I should not depend on PythonDaemon module anymore
   because the module sometime doesn't work as I expect,
   stopping the daemon but it remains running,
   and asking the maintainer doesn't respond for months.

I have studies the implementation
for this porting.

The current implementation is
parsing /proc/diskstats every seconds
and the relavant code in kernel is to read
disk_stats structure through part_stat_read(part, field) macro.

Also, I have a good idea for locking.
I supporse I don't need to add another lock in this porting.

However, of course, possible cons to my idea
is worrying the kernel code becoming more complex.


If you have experienced the same situation
and have some advice on this issue
please tell me.

Akira

Re: [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel

[Joe Thornber]

On Mon, Sep 16, 2013 at 05:54:15PM +0900, Akira Hayakawa wrote:
> Hi, DM Guys,
> 
> I am thinking of a little design change
> as to autonomous migration feature.
> I want to share this issue with you
> to first ask for your advice
> and for you to deeply understand the 
> functionality of dm-writeboost at the same time.

I'm a bit confused.  On the one hand you've asked for this to be
included in linux-next, yet on the other you're still making big
design changes.

When you first posted this code I said you'd need to get some people
behind it who are using this successfully.  How far along this path
are you?

- Joe

Re: [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel

[Akira Hayakawa]

Joe,

> I'm a bit confused.  On the one hand you've asked for this to be
> included in linux-next, yet on the other you're still making big
> design changes.
I am sorry for confusing you.

But I believe it is not a big design change.
Porting the daemon to kernel remains most of the code unchanged. 
There are already two daemons in-kernel, flush_work and migrate_work,
and new daemon can be implemented just like them
and implementing daemon is usually loose-coupled.
If changing the design is absolutely prohibited after asking for staging,
I apologize it for all of you.

But if this issue is to discuss sooner or later, the time is now.
This is why I posted this issue at this point of time.

My plan is to fix this issue
and post v2 patch against the latest linux-next.
Also, planning to add more comments is included in my plan.
Few of my colleagues pointed out that my code needs more comments.

> When you first posted this code I said you'd need to get some people
> behind it who are using this successfully.  How far along this path
> are you?
Actually, no progress.
Asking for staging is for getting 3rd party users which is your request.
This is kind of a chicken and egg problem.
Without staging, I think I have no chance of those users and
staging tree exists for this purpose.

Akira

Re: [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel

[Joe Thornber]

On Mon, Sep 16, 2013 at 07:13:19PM +0900, Akira Hayakawa wrote:
> > When you first posted this code I said you'd need to get some people
> > behind it who are using this successfully.  How far along this path
> > are you?
> Actually, no progress.
> Asking for staging is for getting 3rd party users which is your request.
> This is kind of a chicken and egg problem.
> Without staging, I think I have no chance of those users and
> staging tree exists for this purpose.

Is anyone using your new target other than you?  You've posted on
dm-devel, you've posted on lkml, has anyone bothered to try it?

- Joe

Re: [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel

[Akira Hayakawa]

Joe,

> Is anyone using your new target other than you?  You've posted on
> dm-devel, you've posted on lkml, has anyone bothered to try it?
Unfortunately, the answer is NO.

Some Japanese kernel developers once tried to use it
but didn't reached operation eventually.

But, I am feeling dm-writeboost gathering attention from storage engineers.
That I can not get 3rd party users right now is not because dm-writeboost is trivial.
I believe the target is worth merging in the future.

For example, dm-writeboost is discussed in the Russian website below
http://www.opennet.ru/opennews/art.shtml?num=37864
AND
also in Phoronix
http://phoronix.com/forums/showthread.php?84073-A-New-Log-Structured-Linux-Caching-Software-Driver#post354983

My conclusion is
there are potential users and I think I can greet them as users trying dm-writeboost
if the target is staged.

This issue of porting the userland daemon to in-kernel
is for them to use software of my best efforts.
If the design issue is raised again after all, all I can do it to nothing but fix it.

My regret is that I should have fixed this issue before proposal to staging tree.
PythonDaemon module being unstable was already found before that
although I didn't consider the design is bad.

Akira