From: Akira Hayakawa <ruby.wktk@gmail.com>
To: dm-devel@redhat.com
Cc: gregkh@linuxfoundation.org
Subject: [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel
Date: Mon, 16 Sep 2013 17:54:15 +0900 [thread overview]
Message-ID: <5236C737.7040306@gmail.com> (raw)
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
next reply other threads:[~2013-09-16 8:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-16 8:54 Akira Hayakawa [this message]
2013-09-16 9:21 ` [RFC] dm-writeboost: Porting daemon modulating migration from userland into the kernel Joe Thornber
2013-09-16 10:13 ` Akira Hayakawa
2013-09-16 11:06 ` Joe Thornber
2013-09-16 11:49 ` Akira Hayakawa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5236C737.7040306@gmail.com \
--to=ruby.wktk@gmail.com \
--cc=dm-devel@redhat.com \
--cc=gregkh@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.