From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Weijie Yang <weijie.yang@samsung.com>,
'Andrew Morton' <akpm@linux-foundation.org>,
ngupta@vflare.org, 'Weijie Yang' <weijie.yang.kh@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] zram: clear disk io accounting when reset zram device
Date: Sat, 30 May 2015 13:16:38 +0900 [thread overview]
Message-ID: <20150530041638.GA525@swordfish> (raw)
In-Reply-To: <20150529145418.GG11609@blaptop>
On (05/29/15 23:54), Minchan Kim wrote:
> I think the problem is caused from weired feature "reset" of zram.
agree.
> Until a while ago, we didn't have hot_add/del feature so we should
> use custom reset function but now we have hot/add feature.
> So reset is logically same feature(ie, reset = hot_remove+hot_add
> but remains same device id).
>
hm, sounds interesting, but I think it will end up being tricky.
zram_remove() will be called from device's sysfs node (now we call it from
zram_control sysfs class node, makes a huge difference). sysfs locks the node
until node's read/write handler returns back, so zram_remove() will be called
with lock(s_active#XXX) being locked (we had a lockdep splat with these locks
recently), while zram_remove()->sysfs_remove_group() will once again attempt
to lock this node (the very same lock(s_active#XXX)). in other words, we cannot
fully remove zram device from its sysfs attr. and I don't want to add any bool
flags to zram_remove() and zram_add() indicating that this is a "partial" device
remove: don't delete device's sysfs group in remove() and don't create it in add().
doing reset from zram_control is easy, for sure:
lock idr mutex,
do zram_remove() and zram_add()
unlock idr lock.
`echo ID > /sys/.../zram_control/reset`
no need to modify remove()/add() -- idr will pick up just released idx,
so device_id will be preserved. but it'll be hard to drop the per-device
`reset` attr and to make it a zram_control attr. things would have been
much simpler if all of zram users were also zramctl users. zramctl, from
this point of view, lets us change zram interfaces easily -- we merely need
to teach/modify zramctl, the rest is transparent.
-ss
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Weijie Yang <weijie.yang@samsung.com>,
"'Andrew Morton'" <akpm@linux-foundation.org>,
ngupta@vflare.org, "'Weijie Yang'" <weijie.yang.kh@gmail.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] zram: clear disk io accounting when reset zram device
Date: Sat, 30 May 2015 13:16:38 +0900 [thread overview]
Message-ID: <20150530041638.GA525@swordfish> (raw)
In-Reply-To: <20150529145418.GG11609@blaptop>
On (05/29/15 23:54), Minchan Kim wrote:
> I think the problem is caused from weired feature "reset" of zram.
agree.
> Until a while ago, we didn't have hot_add/del feature so we should
> use custom reset function but now we have hot/add feature.
> So reset is logically same feature(ie, reset = hot_remove+hot_add
> but remains same device id).
>
hm, sounds interesting, but I think it will end up being tricky.
zram_remove() will be called from device's sysfs node (now we call it from
zram_control sysfs class node, makes a huge difference). sysfs locks the node
until node's read/write handler returns back, so zram_remove() will be called
with lock(s_active#XXX) being locked (we had a lockdep splat with these locks
recently), while zram_remove()->sysfs_remove_group() will once again attempt
to lock this node (the very same lock(s_active#XXX)). in other words, we cannot
fully remove zram device from its sysfs attr. and I don't want to add any bool
flags to zram_remove() and zram_add() indicating that this is a "partial" device
remove: don't delete device's sysfs group in remove() and don't create it in add().
doing reset from zram_control is easy, for sure:
lock idr mutex,
do zram_remove() and zram_add()
unlock idr lock.
`echo ID > /sys/.../zram_control/reset`
no need to modify remove()/add() -- idr will pick up just released idx,
so device_id will be preserved. but it'll be hard to drop the per-device
`reset` attr and to make it a zram_control attr. things would have been
much simpler if all of zram users were also zramctl users. zramctl, from
this point of view, lets us change zram interfaces easily -- we merely need
to teach/modify zramctl, the rest is transparent.
-ss
next prev parent reply other threads:[~2015-05-30 4:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 3:23 [PATCH] zram: clear disk io accounting when reset zram device Weijie Yang
2015-05-29 3:23 ` Weijie Yang
2015-05-29 3:41 ` Sergey Senozhatsky
2015-05-29 3:41 ` Sergey Senozhatsky
2015-05-29 14:54 ` Minchan Kim
2015-05-29 14:54 ` Minchan Kim
2015-05-30 4:16 ` Sergey Senozhatsky [this message]
2015-05-30 4:16 ` Sergey Senozhatsky
-- strict thread matches above, loose matches on Subject: below --
2015-06-04 1:53 Minchan Kim
2015-06-04 1:53 ` Minchan Kim
2015-06-04 2:32 ` Sergey Senozhatsky
2015-06-04 2:32 ` Sergey Senozhatsky
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=20150530041638.GA525@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=weijie.yang.kh@gmail.com \
--cc=weijie.yang@samsung.com \
/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.