From: Minchan Kim <minchan@kernel.org>
To: Phillip Lougher <phillip@lougher.demon.co.uk>
Cc: linux-kernel@vger.kernel.org, ch0.han@lge.com, gunho.lee@lge.com
Subject: Re: [RFC,3/5] squashfs: remove cache for normal data page
Date: Mon, 7 Oct 2013 09:53:57 +0900 [thread overview]
Message-ID: <20131007005357.GA12810@bbox> (raw)
In-Reply-To: <524E5C8B.7090807@lougher.demon.co.uk>
On Fri, Oct 04, 2013 at 07:13:31AM +0100, Phillip Lougher wrote:
> Minchan Kim <minchan@kernel.org> wrote:
> >Sqsuashfs have used cache for normal data pages but it's pointless
> >because MM already has cache layer and squashfs adds extra pages
> >into MM's page cache when it reads a page from compressed block.
> >
> >This patch removes cache usage for normal data pages so it could
> >remove unnecessary one copy
>
> 1. As I mentioned last week, the use of the "unnecessary" cache is there
> to prevent two or more processes simultaneously trying to read the same
> pages. Without this, such racing processes will decompress the same
> blocks repeatedly.
>
> It is easy to dismiss this as an rare event, but, when it happens it
> has a major impact on performance, because the racing processes
> can get stuck in a lock-step arrangement, repeatedly trying to access
> the same blocks until the eof. If the file is many megabytes or
> gigabytes in size (such as when Squashfs is used as a container fs for
> cetain liveCDs, or virtual machine disk images) this will lead to
> a significant reduction in performance.
>
> So I consider this a major regression.
>
> 2. You patch also adds another regression, which is to reintroduce
> kmap() rather than kmap_atomic().
>
> I was asked to remove this at my first submission attempt
> in 2005
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0503.2/0809.html
>
> So I'm not particularly willing to reintroduce it now.
>
> 3. Your patch potentially reintroduces this bug
>
> http://www.spinics.net/lists/linux-fsdevel/msg02555.html
> http://zaitcev.livejournal.com/86954.html
>
> 4. You patch is unconditional. With such code changes as this
> it is always essential to make this a "buy in option", with the
> original behaviour retained as default. Otherwise, lots of users
> potentially find their embedded/enterprise/mission critical
> system unexpectedly breaks when upgrading the kernel, and I get
> a lot of angry email.
>
> Phillip
I will handle all your points in next patchset.
Thanks for the review!
--
Kind regards,
Minchan Kim
next prev parent reply other threads:[~2013-10-07 0:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-04 6:13 [RFC,3/5] squashfs: remove cache for normal data page Phillip Lougher
2013-10-07 0:53 ` Minchan Kim [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-09-16 7:08 [RFC 0/5] squashfs enhance Minchan Kim
2013-09-16 7:08 ` [RFC 3/5] squashfs: remove cache for normal data page Minchan Kim
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=20131007005357.GA12810@bbox \
--to=minchan@kernel.org \
--cc=ch0.han@lge.com \
--cc=gunho.lee@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=phillip@lougher.demon.co.uk \
/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.