From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>, Nitin Gupta <ngupta@vflare.org>,
Jerome Marchand <jmarchan@redhat.com>,
Ganesh Mahendran <opensource.ganesh@gmail.com>
Subject: Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request
Date: Mon, 2 Feb 2015 10:59:40 +0900 [thread overview]
Message-ID: <20150202015940.GB6977@swordfish> (raw)
In-Reply-To: <20150202014315.GC6402@blaptop>
On (02/02/15 10:43), Minchan Kim wrote:
> > static inline int init_done(struct zram *zram)
> > {
> > - return zram->meta != NULL;
> > + return atomic_read(&zram->refcount);
>
> As I said previous mail, it could make livelock so I want to use disksize
> in here to prevent further I/O handling.
just as I said in my previous email -- is this live lock really possible?
we need to umount device to continue with reset. and umount will kill IOs out
of our way.
the other reset caller is __exit zram_exit(). but once again, I don't
expect this function being executed on mounted device and module being
in use.
> > +static inline void zram_put(struct zram *zram)
> > +{
> > + if (atomic_dec_and_test(&zram->refcount))
> > + complete(&zram->io_done);
> > +}
>
> Although I suggested this complete, it might be rather overkill(pz,
> understand me it was work in midnight. :))
> Instead, we could use just atomic_dec in here and
> use wait_event(event, atomic_read(&zram->refcount) == 0) in reset.
>
yes, I think it can do the trick.
-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@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux-MM <linux-mm@kvack.org>, Nitin Gupta <ngupta@vflare.org>,
Jerome Marchand <jmarchan@redhat.com>,
Ganesh Mahendran <opensource.ganesh@gmail.com>
Subject: Re: [PATCH v1 2/2] zram: remove init_lock in zram_make_request
Date: Mon, 2 Feb 2015 10:59:40 +0900 [thread overview]
Message-ID: <20150202015940.GB6977@swordfish> (raw)
In-Reply-To: <20150202014315.GC6402@blaptop>
On (02/02/15 10:43), Minchan Kim wrote:
> > static inline int init_done(struct zram *zram)
> > {
> > - return zram->meta != NULL;
> > + return atomic_read(&zram->refcount);
>
> As I said previous mail, it could make livelock so I want to use disksize
> in here to prevent further I/O handling.
just as I said in my previous email -- is this live lock really possible?
we need to umount device to continue with reset. and umount will kill IOs out
of our way.
the other reset caller is __exit zram_exit(). but once again, I don't
expect this function being executed on mounted device and module being
in use.
> > +static inline void zram_put(struct zram *zram)
> > +{
> > + if (atomic_dec_and_test(&zram->refcount))
> > + complete(&zram->io_done);
> > +}
>
> Although I suggested this complete, it might be rather overkill(pz,
> understand me it was work in midnight. :))
> Instead, we could use just atomic_dec in here and
> use wait_event(event, atomic_read(&zram->refcount) == 0) in reset.
>
yes, I think it can do the trick.
-ss
next prev parent reply other threads:[~2015-02-02 1:59 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 8:15 [PATCH 1/2] zram: free meta table in zram_meta_free Minchan Kim
2015-01-28 8:15 ` [PATCH v1 2/2] zram: remove init_lock in zram_make_request Minchan Kim
2015-01-28 14:56 ` Sergey Senozhatsky
2015-01-28 14:56 ` Sergey Senozhatsky
2015-01-28 15:04 ` Sergey Senozhatsky
2015-01-28 15:04 ` Sergey Senozhatsky
2015-01-28 23:33 ` Minchan Kim
2015-01-28 23:33 ` Minchan Kim
2015-01-29 1:57 ` Sergey Senozhatsky
2015-01-29 2:01 ` Minchan Kim
2015-01-29 2:01 ` Minchan Kim
2015-01-29 2:22 ` Sergey Senozhatsky
2015-01-29 2:22 ` Sergey Senozhatsky
2015-01-29 5:28 ` Minchan Kim
2015-01-29 5:28 ` Minchan Kim
2015-01-29 6:06 ` Sergey Senozhatsky
2015-01-29 6:06 ` Sergey Senozhatsky
2015-01-29 6:35 ` Minchan Kim
2015-01-29 6:35 ` Minchan Kim
2015-01-29 7:08 ` Sergey Senozhatsky
2015-01-29 7:08 ` Sergey Senozhatsky
2015-01-30 14:41 ` Minchan Kim
2015-01-30 14:41 ` Minchan Kim
2015-01-31 11:31 ` Sergey Senozhatsky
2015-01-31 11:31 ` Sergey Senozhatsky
2015-02-01 14:50 ` Sergey Senozhatsky
2015-02-01 14:50 ` Sergey Senozhatsky
2015-02-01 15:04 ` Sergey Senozhatsky
2015-02-01 15:04 ` Sergey Senozhatsky
2015-02-02 1:43 ` Minchan Kim
2015-02-02 1:43 ` Minchan Kim
2015-02-02 1:59 ` Sergey Senozhatsky [this message]
2015-02-02 1:59 ` Sergey Senozhatsky
2015-02-02 2:45 ` Minchan Kim
2015-02-02 2:45 ` Minchan Kim
2015-02-02 3:47 ` Sergey Senozhatsky
2015-02-02 3:47 ` Sergey Senozhatsky
2015-02-02 1:30 ` Minchan Kim
2015-02-02 1:30 ` Minchan Kim
2015-02-02 1:48 ` Sergey Senozhatsky
2015-02-02 1:48 ` Sergey Senozhatsky
2015-02-02 2:44 ` Minchan Kim
2015-02-02 2:44 ` Minchan Kim
2015-02-02 4:01 ` Sergey Senozhatsky
2015-02-02 4:01 ` Sergey Senozhatsky
2015-02-02 4:28 ` Minchan Kim
2015-02-02 4:28 ` Minchan Kim
2015-02-02 5:09 ` Sergey Senozhatsky
2015-02-02 5:09 ` Sergey Senozhatsky
2015-02-02 5:18 ` Minchan Kim
2015-02-02 5:18 ` Minchan Kim
2015-02-02 5:28 ` Sergey Senozhatsky
2015-02-02 5:28 ` Sergey Senozhatsky
2015-02-02 5:10 ` Minchan Kim
2015-02-02 5:10 ` Minchan Kim
2015-01-30 0:20 ` Sergey Senozhatsky
2015-01-29 13:48 ` Ganesh Mahendran
2015-01-29 13:48 ` Ganesh Mahendran
2015-01-29 15:12 ` Sergey Senozhatsky
2015-01-29 15:12 ` Sergey Senozhatsky
2015-01-30 7:52 ` Ganesh Mahendran
2015-01-30 7:52 ` Ganesh Mahendran
2015-01-30 8:08 ` Sergey Senozhatsky
2015-01-30 8:08 ` Sergey Senozhatsky
2015-01-31 8:50 ` Ganesh Mahendran
2015-01-31 8:50 ` Ganesh Mahendran
2015-01-31 11:07 ` Sergey Senozhatsky
2015-01-31 11:07 ` Sergey Senozhatsky
2015-01-31 12:59 ` Ganesh Mahendran
2015-01-31 12:59 ` Ganesh Mahendran
2015-01-28 14:19 ` [PATCH 1/2] zram: free meta table in zram_meta_free Sergey Senozhatsky
2015-01-28 14:19 ` Sergey Senozhatsky
2015-01-28 23:17 ` Minchan Kim
2015-01-28 23:17 ` Minchan Kim
2015-01-29 1:49 ` Ganesh Mahendran
2015-01-29 1:49 ` Ganesh Mahendran
-- strict thread matches above, loose matches on Subject: below --
2015-02-02 3:41 [PATCH v1 2/2] zram: remove init_lock in zram_make_request Minchan Kim
2015-02-02 3:41 ` Minchan Kim
2015-02-02 5:59 ` Sergey Senozhatsky
2015-02-02 5:59 ` Sergey Senozhatsky
2015-02-02 6:18 ` Minchan Kim
2015-02-02 6:18 ` Minchan Kim
2015-02-02 7:06 ` Sergey Senozhatsky
2015-02-02 7:06 ` Sergey Senozhatsky
2015-02-03 1:54 ` Sergey Senozhatsky
2015-02-03 1:54 ` Sergey Senozhatsky
2015-02-03 3:02 ` Minchan Kim
2015-02-03 3:02 ` Minchan Kim
2015-02-03 3:56 ` Sergey Senozhatsky
2015-02-03 3:56 ` 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=20150202015940.GB6977@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=jmarchan@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=opensource.ganesh@gmail.com \
--cc=sergey.senozhatsky@gmail.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.